We use Xubuntu 14.04 64-bit with modern fat clients (Intel Ivy Bridge) 
on a gigabit LAN. Fat clients have 2 GB RAM each, with around 1600 MB 
available after the onboard graphics allocation.

We have NBD swap enabled (8 GB) and we have quite a few users who 
regularly spill over into swap space, despite swappiness being set to 10.

We are getting frequent very long pauses / halts of fat clients which 
are swapping, eventually requiring reboots for those users. Affected 
users reboot 1 - 2 times per day because of this. I feel something is 
going wrong with NBD swap. We never had this issue on much less powerful 
fat clients (7 year old Athlons) on Xubuntu 12.04 32-bit, mostly with 
1GB RAM, some with 2 GB RAM.

When this happens:

  - nbd-client CPU usage is very high.

  - There is a steady stream of data being sent from the server to the 
client - presumably this is the requested swap, but it goes on for too 
long at too high a rate to be reasonable - if it's sending 30+ megabytes 
/ sec for 90+ seconds, that's 2.7 GB transferred when TOTAL swap used is 
only 800 MB. I don't know how this works, but that doesn't seem to make 
sense to me.

  - If machines are left in peace for long enough (a number of minutes) 
they usually recover, but the next action (like switching browser tabs) 
brings on the same behaviour. From a user's perspective, the system has 
"crashed" and they reboot.

Here's a screenshot of the client's htop and server's bmon during such 
an instance:
http://i.imgur.com/29MRnvT.png

In this case it's just a VM fat client with 1 GB RAM, but it's the same 
for real fat clients with more memory.

Any ideas what could be going wrong? Do we just need to throw more RAM 
at the clients? :(

Side note: Modern browsers consume ridiculous amounts of memory on 
complex sites like Google Docs and Office 365 - in excess of 400 MB with 
just a handful of tabs open is not unusual for us. Normal?

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Reply via email to