On Fri, 30 Jan 2004, Jeff Nelson wrote: > Jim, > Thanks! Enabling NFS swap made a dramatic difference (no lockups), > although it hasn't eliminated the crashes entirely. > > One of my Jammin 125 clients was practically unusable, it would lock up > and/or crash so often. With 128m NFS swap enabled, I was able to start > it up and happily run more than a dozen programs without a lockup. So, > thinking that maybe 128m was more than enough, I reduced it to 64m. The > next user came along and had an X-server crash after about 5 minutes > while playing a game. > > After that crash, I changed the swap back to 128m. The user's X session > lasted about 30 minutes (playing a game) and then it crashed again. > And again, after about 10 minutes of additional gameplay (tuxmath). > > Is 128m overkill? Is it enough? Is there anything else I can do to > stop these crashes? > > The other Jammin clients crash much more rarely than this one. Could > there be a hardware problem?
Well, the fact that adding (and increasing) the amount of swap has an effect on how long it runs makes me think that you've got a program that is allocating memory and not freeing it. Actually, it is asking the X server to allocate memory. Lots of things will cause the X server to need more memory, like fonts and bitmaps. Also, there are an awful lot of installations with Jammin-125's running with LTSP-4 (I'm running it here) and nobody else has reported a problem. With LTSP-4, we have a daemon running on the client that you can query for information about its current state. For instance, you can read the /proc/meminfo file and see how much ram is currently being used. BUT, you need to enable that feature in lts.conf ALLOW_PROCREAD = Y Setting that, and rebooting the client will give you access to any file in the /proc filesystem on the workstation. To actually read the file, you can do this: telnet ws001 9200 Then, when you get the 'Escape char......' prompt, you should be able to type: getproc meminfo and it should spew out lots of details about the current memory usage. Run this several times while the user is running the apps, and see if it shows increased memory usage. If it does, then you've got a memory leak problem. This could be caused by alot of things. If you determine that it is consuming and not releasing memory, then we can start digging into which apps are doing it. Jim McQuillan [EMAIL PROTECTED] > > Jeff > > El vie, 30-01-2004 a las 23:34, [EMAIL PROTECTED] escribió: > > Jeff, > > > > Try turning on NFS_SWAP, and see if that has any effect. > > > > Jim McQuillan > > [EMAIL PROTECTED] > > > > > > > > On Wed, 28 Jan 2004, Jeff Nelson wrote: > > > > > Hi everyone, > > > > > > Well, my little Colombian computer lab is whizzing right along now, > > > except for a lot of crashes and lockups on the clients. It seems to > > > only happen on the Jammin 125 machines, which makes me think it's > > > something to do with the new X server. I can duplicate it pretty > > > faithfully just by opening up a bunch of windows on the client, > messing > > > around a bit, and within a couple of minutes the screen will lock > up. > > > That's in Gnome. In KDE, my session can last much longer, and it > > > doesn't lock up, but rather just crashes and restarts. Well, > actually, > > > sometimes it crashes immediately as soon as I press return on the > login > > > screen! > > > > > > How can I troubleshoot this? > > > > > > (Am I going to have to go back to ltsp3?) > > > > > > Jeff > > > > ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _____________________________________________________________________ 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
