Date: Wed, 23 Oct 1996 16:01:29 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: hackers@freebsd.org Subject: Exceedingly slooooow filesystem operations Message-ID: <199610232101.QAA10462@brasil.moneng.mei.com>
next in thread | raw e-mail | index | archive | help
Hello, I have a little problem I am looking at. I am currently tackling this from the application end, so I am not particularly interested in answers referring me back to the application domain. I have a news server. Article writes are really butt slow. It didn't used to be like this. What is the best course of action, from a kernel or system point of view, to find out what the heck is causing such a slowdown? I have looked at the I/O statistics and they are not as good as another machine with all fast disks, but I do not see why having some disks that are half as fast result in a substantially reduced lookup speed. (I should point out that the majority of this is happening on equivalently fast disks.) Namei calls is 422 (name cache 72% hit rate) on the slow machine. Article write time is 250.742 seconds to write 1029 articles. That is 243ms per article. The machine is virtually saturated as the sample period is 300 seconds. Namei calls is 2707 (name cache 95% hit rate) on the fast machine. Article write time is 68.635 seconds to write 1019 articles. That is 67ms per article. That is a little puzzling. What can I do to find out what is happening in the kernel? Is profiling working yet? Does anyone have any insight into how to go about identifying this from a kernel point of view? (I am already working on it from the application point of view). Kernel suggestions welcome! ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610232101.QAA10462>