topic Re: drop cache file in SUSE 9.0 in Operating System - Linux

drop cache file in SUSE 9.0

sacthivel.C — Wed, 14 Jul 2010 05:41:12 GMT

Dear all,
we are using SUSE linux 9.0 in our servers. In one of the server we want to clear the drop cache (cache memory free).But we didn't find any drop_caches file inside /proc/sys/vm.

Would somebody help me to do this activity?

Regards,
C.Sacthivel

Re: drop cache file in SUSE 9.0

Matti_Kurkela — Wed, 14 Jul 2010 07:17:05 GMT

In production systems, there should never be any practical need to drop the caches. The drop_caches file was added in kernel version 2.6.16 to help kernel and storage benchmarking (performance testing).

SuSE Linux 9.0 has an older kernel, so it does not have this feature.

You may think the caches are preventing you from running big applications, but it isn't true. Please read this web page to find a really simple description of how the Linux caches work:

http://www.linuxatemyram.com/

MK

Re: drop cache file in SUSE 9.0

sacthivel.C — Wed, 14 Jul 2010 08:59:18 GMT

Hi MK,
Thanks for the reply and the link.
I will explain to you why I want to do this.
We ran the command "partprobe" after we add one new partition(from SAN box - iscsi).
After executing the partprobe (without any option),it is running for the past 2 days and it is not possible for me to check whether it is running or it get hung. I tried by killing the process also. But it was not getting killed.As this machine is a production server,the work load is always high.It is not possible for me to come to a conclusion that whether the partprobe take this much of time or whether it is an iscsi issue or storage side issue or OS side issue or resource not available.

Would you help me to come out of this?

Regards,

C.Sacthivel

Re: drop cache file in SUSE 9.0

Matti_Kurkela — Wed, 14 Jul 2010 12:11:51 GMT

> After executing the partprobe (without any option),it is running for the past 2 days and it is not possible for me to check whether it is running or it get hung.

Use "ps -e |grep [p]artprobe" to find the process ID of the partprobe process. Then run "ps -fp " and look at the TIME column. This indicates the amount of CPU time this process has used so far. If it has been working for 2 days, it should have used a significant amount of CPU time. But if the TIME value is very small (like 00:00:01 or so), the process is probably hung.

> I tried by killing the process also. But it was not getting killed.

If it does not die with "kill -9", then it usually means the process is executing a system call, and the system call is hung inside the kernel code... which is pretty serious.

If you cannot find and fix the root cause of the hang, you might have to reboot the system to clear the hung partprobe process.

In this case, NFS filesystems are probably not an issue (since partprobe deals with actual disk devices, not with filesystems at all), but iSCSI connectivity problems might be.

Is there anything relevant in the syslog? (Check the log files in /var/log.)

Also please run "dmesg" and see if there is somethign that might be relevant to this problem.

Hmm... you say it's a SUSE Linux 9.0? According to Wikipedia it was released in 2003 and uses a 2.4.21 kernel. But iSCSI support was introduced to Linux in 2005, with the 2.6.12 kernel. Something does not add up...

SUSE Linux 9.3 was released in April 2005, and includes a 2.6.11 kernel, so it would be much more reasonable to backport iSCSI support to 9.3, than to 9.0. Still, just by looking at the release dates, I would have serious doubts about the quality and "production-readiness" of the iSCSI support in SUSE Linux 9.x.

http://en.wikipedia.org/wiki/Iscsi
http://en.wikipedia.org/wiki/OpenSUSE

How new is the iSCSI SAN box? Is SUSE Linux 9.x listed as supported by the SAN box manufacturer?

MK

Re: drop cache file in SUSE 9.0

macosta — Wed, 14 Jul 2010 22:23:46 GMT

> Use "ps -e |grep [p]artprobe" to find the process ID of the partprobe process.

Additionally, it may be helpful to run:
$ ps -ely |grep [p]artprobe

If the first column shows "D", you're stuck waiting on I/O for some reason. Even on a busy system, an ioctl should not take 2 days - something may be amiss here.

Don't mess with cache unless you know why you're doing it, and you have a really good reason to do so, even more so on a production system.