Bug 220350

Summary: Something is eating up memory on 10.1-x86_64
Product: [openSUSE] SUSE Linux 10.1 Reporter: Mathias Homann <Mathias.Homann>
Component: ZenworksAssignee: E-mail List <zlm-code10-bugs>
Status: RESOLVED WONTFIX QA Contact: Jawaad Tariq <jtariq>
Severity: Normal    
Priority: P5 - None    
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: SuSE Linux 10.1   
Whiteboard:
Found By: Customer Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Mathias Homann 2006-11-13 09:36:02 UTC
I've got two machines running 10.1 here, a p4 and a sempron64.

here's `free` on the i686:
lemmy@gildor:~> free
             total       used       free     shared    buffers     cached
Mem:        516432     356856     159576          0        592     256936
-/+ buffers/cache:      99328     417104
Swap:      1574328          0    1574328


here's `free` on the amd:
mathias@pippin:~> free
             total       used       free     shared    buffers     cached
Mem:        898296     685344     212952          0       1088     316348
-/+ buffers/cache:     367908     530388
Swap:      1582360        168    1582192


both machines are fresh after boot, with noone logged in except me via SSH, both are in runlevel 5, and both are running the same services.
Note that on the x86_64 box, 3.7 times as much ram is being used than on the i686. Even with int and void* being 64bits instead of 32bits this doesnt make sense.
Comment 1 Matej Horvath 2006-11-15 09:35:36 UTC
Please run the 'top', find out which process has the highest memory usage and post it here.
Comment 2 Mathias Homann 2006-11-15 21:52:45 UTC
on the x86_64 box:
 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3655 root      34  19  178m  53m 6952 S  0.3  6.0   0:37.59 zmd
16422 root      15   0 98.8m  33m 7428 S  0.0  3.8   0:02.96 X
 3512 vscan     18   0 50896  24m 1584 S  0.0  2.7   0:03.38 clamd
16432 root      15   0 91384  20m  16m S  0.0  2.3   0:01.18 kdm_greet
 3654 ntp       15   0 13856 4732 3604 S  0.0  0.5   0:00.06 ntpd

Seems like zmd and X are the worst mem hogs.

on the i686 box:
 3641 root      15   0 66408  39m 4488 S  4.7  7.7   0:53.57 stext     Xorg
 3342 root      34  19 99.5m  34m 7676 S  0.0  6.8   0:10.04 stext     zmd
 9237 root      18   0 67212  30m 6224 R  8.3  6.0   0:06.44 stext     update-status
 2388 root      16   0  4424 3056 1472 S  0.0  0.6   0:02.20 stext     hald
 3556 root      15   0  4256 1740 1396 S  0.0  0.3   0:00.08 stext     powersaved
 3750 root      16   0  5420 1728 1408 S  0.0  0.3   0:00.01 stext     master
 3673 root      16   0  4320 1704 1216 S  0.0  0.3   0:00.01 wait      kdm
 3495 root      25   0  4960 1200  868 S  0.0  0.2   0:00.02 stext     sshd
 3432 root      16   0  103m 1124  824 S  0.0  0.2   0:00.06 322412572 nscd

zmd is evil as well, but it's still refreshing its sources after boot (see bug https://bugzilla.novell.com/show_bug.cgi?id=220354 for that)

btw, on both machines zmd has the same installation sources configured (which are, I have to admit, quite a lot, 15 sources per box.)
Comment 3 Mathias Homann 2006-11-15 22:00:27 UTC
now that zmd is done refreshing on the i686, it uses a bit more ram, but still much less than on the x86_64:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  WCHAN     COMMAND
 3641 root      15   0 63748  38m 4488 S  4.7  7.6   1:12.27 stext     /usr/X11R6/bin/Xorg -br -nolisten tcp :0 vt7 -auth /va
 3342 root      34  19  108m  36m 7920 S  0.0  7.2   0:11.11 stext     zmd /usr/lib/zmd/zmd.exe
 2388 root      16   0  4424 3056 1472 S  0.0  0.6   0:02.20 stext     /usr/sbin/hald --daemon=yes --retain-privileges
 3556 root      15   0  4256 1740 1396 S  0.0  0.3   0:00.08 stext     /usr/sbin/powersaved -d -f /var/run/acpid.socket -v 3
 3750 root      16   0  5420 1728 1408 S  0.0  0.3   0:00.01 stext     /usr/lib/postfix/master
 3673 root      16   0  4320 1704 1216 S  0.0  0.3   0:00.01 wait      -:0
Comment 4 Stanislav Visnovsky 2007-06-21 13:07:34 UTC
ZMD is dropped from openSUSE.