Slow system performance
This question really encompases allot of different toics, so I thought I'd throw it in here and hope something sticks.
I have 60+ client desktops all running CentOS 5.3 or higher. They are all pretty powerful machines (core2quads and corei7's) with between 4 and 8GB of RAM. The problem is they all run really slow. Frequent system stalls (2-3 secs of unresponsiveness) while running mundane things like emacs and firefox are very common. First I suspected video issues. I have tried both ATI and NVIDIA as well as their respective generic and proprietary drivers with no change. I am serving all user profiles from an NFS/NIS server (quad core 8GB RAM). I am begining to wonder if there is a network bottleneck, or even how to begin troubleshooting that. I'm really at a loss to figure out what the issue is, but it's becoming so bad, clients have been avoiding their desktops and have switched to using their personal (GASP) windows laptops due to the annoyance. Any ideas where I could find start to find out what is bogging down my systems? Either internally or network? |
Dunno but there are quite a few other threads about Centos being slow on this site, e.g. http://www.linuxquestions.org/questi...ed-why-634921/ . Hope some help.:)
|
Hmmm - Centos 5.3 might be too old, but maybe have a look at latencytop.
|
Quote:
Quote:
Quote:
The other question is whether the 2-3 seconds of unresponsiveness is the only kind of slowness that you have? In other words, if you do intense things that are purely local, do those seem fast? What about grabbing files from NFS? Is that OK? Please ensure that you have IPV6 turned off. Also, if the slowness is purely internet-related, you could also check that DNS name lookups are reasonably swift (and not, eg, trying a non-existant nameserver first, before going over to the one that actually does give an answer). If I were to guess, I would guess that, for one reason or another, the systems are doing a lot of waiting (and that might be network or disk); maybe top and friends might show something interesting. |
Thanks for the reply. I do believe it is network or NFS related. A system not mounting NFS has no performance issues. Once connected to our NIS/NFS, performance slows. All home directories mount on the NFS server. It does show considerable disk and network activity, but I would expect the throughput of a system like that to be able to handle it. It has plenty of RAM, 100Mbs Fullduplex, and SATA HD's.
Wireshark didn't show anything glaring, although I was amazed at the number of requests to and from the NFS machine. Not sure if that is normal. gkrellm shows: CPU average 10% Disk average 5.5M Eth0 average 2M |
Is your server's SATA controller set as "IDE emulation" (or something like that, you check that in the BIOS setup)? If it is set like that you'll get a very low throughput (since it's essentially emulating an IDE port). To fix it you need to set it to "SATA" or "AHCI" which is the native mode and will yield the full throughput of your SATA controller/disks.
|
I'm so not not qualified to comment here, but have you tried
* using a custom kernel? * using a different desktop environment? * turning off cron jobs? * Updating frequently used packages to their latest versions? Are you sure the system stalls are random? I mean, generally the kernel can be caught up in disk io for a few seconds and the system may get stuck. You could try the "noasync" flag for mounting the root or other local filesystems. |
Quote:
Quote:
|
Hi
100mbit isn't very fast, it's only a fraction of the speed of a modern SATA disk. Even with one user, it's going to be the bottleneck. |
Quote:
|
Quote:
I administer a bunch of machines that use home directories mounted via NFS. I don't know the exact specs of the server since someone else looks after it, but I do know that it has a networking that's a LOT faster than 100Mbit/s (I'd guess it's 10GbE) and the home directories on are on an Enterprise grade hardware raid array stuffed full of drives that are almost certainly spinning a lot faster than yours are, that's connected to the server via fibre optic. The desktop machines have 1000Mbit/s connections back to the nearest switch. If I run this with the working directory set to my NFS mounted home directory Code:
$ dd if=/dev/zero of=foo bs=1024 count=1048576 Now look at the set up I've just described. Now look at what the server specs you say you have. Now look at mine again and consider how much better it is and that I'm getting 20MB/s which, let's face it, is slow when you compare to a local disk. Try that command for yourself with the working directory set to a NFS share and then again with the working directory set to somewhere on the local disk. You may find the results interesting. When you say Quote:
|
What about the simple things ...
What does ifconfig say? Suspicious errors or dropped packets? Anything about "eth0 link down" in dmesg? Anything suspicious there? Esp on the server? Does the NIC share its IRQ with the graphics? 60 clients are connected to ... what? Is this "what" simply running hot, maybe? Set up a simple ftp server on the server and do some basic throughput/reliability tests to the clients. Do all clients hang at once? Is there some kind of traffic control? Else, this guy with the 4 GB BMP desktop picture of his spouse will eat up other peoples bandwidth. Have a look at "ntop" or similar. Firefox hanging does not say much ... but emacs? What is emacs trying to do when it hangs? Saving something? Is it the X11-emacs or console emacs? Review the stuff stored on the server. There's not much sense in storing Firefox cache, desktop themes and similar things remotely. Does the server use swap? You're not doing wireless, do you? |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
One other thing, we are running a software RAID5, and sitting in the same room as the server, the drives are constantly running (ie: churning away). Maybe we should look into a hardware RAID? Is this more efficient? |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Hardware raid will not stop your harddrives from churning. |
Quote:
|
Quote:
|
Quote:
Quote:
Quote:
Quote:
Thanks for all the suggestions btw. |
Quote:
You should gather more information about your freeze-problem. Edit: Quote:
When I see this list: Quote:
So do a "swapon -s" and check whether the server is using a noticeable amount of swap. Some kb are usual. |
Quote:
/dev/hda3 partition 16386292 148 -1 I also ran iperf. Not sure if that is great tool for networkd performance, but here's the results from the server side with client connects: Server and client IP's have been changed to protect the innocent. server=111.11.111.11 client= 222.22.222.22 ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 111.11.111.11 port 5001 connected with 222.22.222.22 port 53814 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.1 sec 111 MBytes 91.8 Mbits/sec [ 5] local 111.11.111.11 port 5001 connected with 222.22.222.22 port 53815 [ 5] 0.0-10.1 sec 110 MBytes 90.9 Mbits/sec ------------------------------------------------------------ Client connecting to 222.22.222.22, TCP port 5001 TCP window size: 165 KByte (default) ------------------------------------------------------------ [ 5] local 111.11.111.11 port 34319 connected with 222.22.222.22 port 5001 [ 5] 0.0-10.0 sec 108 MBytes 90.4 Mbits/sec [ 4] local 111.11.111.11 port 5001 connected with 222.22.222.22 port 53816 ------------------------------------------------------------ Client connecting to 222.22.222.22, TCP port 5001 TCP window size: 40.3 KByte (default) ------------------------------------------------------------ [ 6] local 111.11.111.11 port 34320 connected with 222.22.222.22 port 5001 [ 6] 0.0-10.0 sec 96.6 MBytes 80.9 Mbits/sec [ 4] 0.0-10.0 sec 92.6 MBytes 77.4 Mbits/sec |
Quote:
Quote:
For the beginning, write a simple script that writes the actual time to a _local_ file, every 500 milliseconds, and execute it on a client affected by the freezes. After that review if really there is a timestamp inside the file all 500 ms. This will tell you whether the whole client freezes or just the gui. To be completely sure, write the file to ramdisk and run the script dispatched. Second, iperf does produce artificial network traffic and measures the result. It's good to see healthy results, but so this does not help us either in finding what is wrong. You need something to record and evaluate your real world traffic, not artificial traffic. Wireshark is not made to do this ... it is made to analyze decent connections and packet contents. ntop is the tool of choice, but it doesn't install for you. "darkstat" is said to be a good replacement for ntop. Some console tools you could try are: "EthStatus", "IPTraf", "Nolad", "iftop", "MRTG" Watch for either peaks in traffic, or "black holes" in traffic, on either the whole network or a single affected client, on a resolution down beyond seconds, not minutes or hours. btw, what about swap usage on the clients? 4 to 8 GB should be more than enough, except there is some memory hog running. Once had all memory and then swap running full due to a buggy KdeIOSlave ... caused lags, freezes and random OOM-kills. And just had KDE Dolphin fill up my tmp directory, causing "disk full" errors ... results on NFS-homes could be interesting ... |
Quote:
I did get ntop installed, but I'm not sure what I should be looking for. So much info, but nothing smaking me in the face as odd. Something I did notice that is odd. If I start top and just drag a terminal box around in the GUI, my CPU usage for both Xorg and firefox jumps to 20% each. Seems excessive for just dragging a stupid box? |
Quote:
Another thing you could check is the hard disk subsystem. Short freezes on the disk controller may lead to gui freezes. But, again, emacs shouldn't suffer from this (except there is swap usage). Look for a tool to measure disk I/O throughput in realtime. And, again, have a look at the swap usage on the clients. Quote:
When running ntop on the server, there are plenty of connections you could monitor. Maybe it is easier to install ntop on a client and let it monitor the traffic ... make sure it probes the traffic on a resolution beyond one second and when there are freezes, look if you see something suspicious in the ntop data. Quote:
Firefox is a resource hog. This is especially true when not using the Adobe Flash plugin but the open source one (gnash I think) and not using Sun Java but the openjdk Java. Looks like you should check whether these freezes are not that kind of random, but directly connected to firefox usage or slow X performance. btw, keep in mind the thing about storing a firefox cache on NFS. |
All times are GMT -5. The time now is 01:01 PM. |