Skip, Let's see if I understand this.
If you just fire up the workstation, it runs for many days with no problem. If you try to run snmp to monitor memory usage, the workstation locks up. Either after 150 minutes or 300 minutes, depending on your method of gathering the memory data. It would be interesting to see how 'locked up' the workstation is. Can you ping it ? What happens if you don't run the browser, but just monitor the memory usage of an idle workstation. What if you don't even run X Windows, just boot to runlevel 3 and do the memory monitoring. Does it lock up then ? Looks like you've got alot of memory in the workstation, what if you reduce it to 16mb or 32mb, what kind of effect does that have on the monitoring ? Are you running with NFS-Swap ? Jim McQuillan [EMAIL PROTECTED] On Mon, 20 May 2002, Skip Gaede wrote: > On Wednesday 15 May 2002 08:53 pm, Brian Fahrlander wrote: > > On Wed, 15 May 2002 20:43:37 -0400, "Skip Gaede" <[EMAIL PROTECTED]> wrote: > > > Folks, > > > > > > I've had a few exchanges with Jim about the "right" way to do this, and I > > > agree that SNMP or a sockets-based app running as a daemon would be a > > > more elegant solution, but I now have running, on a client near me, a > > > script that collects information from the /proc/meminfo file and dumps > > > the results in the system log on the server. Since it's script-based, I > > > plan on making it more elegant, collect more data, and do some filtering, > > > etc. > > > > > > The concept is that I use the at "batch" command to execute a script > > > which sits in an infinite loop. Data is collected into shell variables > > > which are then written to the system log by the logger utility. I chose > > > the batch command, rather than cron or at, because I didn't need to > > > specify an exact time, and I could do the scheduling by simply doing a > > > sleep command in the script... > > > > This sounds like a lot of trouble; I got snmp to work and it was > > telling me ALL the information about processes, available ram, drive space, > > even the durned kernel BOOT strings, fcol. If you're a regular > > programmer-kinda guy, I have at it, but if you get back to SNMP, I can > > source you the config files that'll allow you to use existing tools like > > tkined and such. Let me know if you want to go this way; I'd be happy to > > help you out with my prrvious work if you like. > > This is an update on my instrumentation experiment. I managed to get SNMP > working on the client after fixing a bug in the SNMP code. I setup a small > perl script to collect the amount of free memory, the system name, and the > system UpTime at 5 minute intervals and started data collection shortly after > booting the client. On the client, I started a web browser and left it > sitting there. My experiment terminated at about 150 minutes with a client > lockup. I then repeated the experiment using my "bash script" approach, and > got the same results, except the lockup occurred after about 300 minutes. > Since I've left a client running for days with the browser running, I'm > surprised. > > A plot of the data is attached for your viewing enjoyment. > > --Skip > > -- _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ _____________________________________________________________________ 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.openprojects.net
