Tag Info

New answers tagged

0

With a server with that much idle time I would suspect some kind of hardware problem. Linux does not kernel panic regularly just for fun, not even in virtual machines. "Task blocked for more than..." would indicate that there are some problems with the disk I/O. What kind of storage is in use?


0

Did you check the memory utilization prior to reboot sar -r -f <sa file> what about number of transaction executing per second sar -d -f<sa file> and anything related to system load sar -q -f <sa file> Are you able to capture any kernel oops prior to panic as you mentioned in question task blocked? Is kdump ...


3

Sounds like CVE-2011-3188 which has been fixed since the RedHat kernel 2.6.18-274.7.1.el5. So either that server isn't running the kernel you mention (installed but not rebooted?), it tested the wrong system (some transparent device between the check and the server?) or it is a false positive (unsure why).


1

I started just trying stuff, and I seem to have stumbled on the answer. On the client, the line for mounting the passwd, group, shadow, and gshadow files in /etc/fstab was like this: server_name:/etc/sub_dir/ /etc/sub_dir/ nfs rw,sync,hard,intr 0 0 I have changed it to this: server_name:/etc/sub_dir/ /etc/sub_dir/ ...


1

I addressed an issue in the DBA StackExchange about the kernel and journaling. I learned this from Percona back in May that a certain flush behavior is actually simulated. You may have to change how journaling is done. You may have to tune InnoDB Loosening ACID compliance for write performance (setting innodb_flush_log_at_trx_commit to 0 or 2) Larger ...


3

The kernel error messages indicate it was not able to schedule a process to run for 120 seconds. It's either extreme high CPU usage or contention at the I/O level. I would recommend against using NFS to share system critical files like /etc/passwd or even symlinks because the very NFS operations is dependent on them. You could think about setting up a ...


0

The command itself should complete instantaneously. The consequences, i.e. everything needs to be cached again, can take a lot of time. It doesn't make sense: if you can remove it completely it would be a good idea. Maybe you are looking at the wrong command: does it executes also a sync before echo 3 > /proc/sys/vm/drop_caches, such in sync; echo 3 ...



Top 50 recent answers are included