Использование памяти программами и memstat, ps

Вас эти KB действительно сильно волнуют?

А вообще прочитайте внимательно man на эти программы - там есть некоторые объяснения.

Я их читал. Лишний раз сейчас заглянул, но не нашел ответа на мой вопрос. Если не сложно, то можно меня в конкретные строки ткнуть?

Согласно описанию memstat-tutorial.txt.gz сумма должна совпадать.

Блин, сейчас на их примере про getty посмотрел - тоже не сходится, но в другую сторону.

ps aux |grep 3282 root 3282 0.0 0.0 1600 500 tty2 Ss+ 12:55 0:00 /sbin/getty 38400 tty2

% memstat -w |grep 3282 256k: PID 3282 (/lib/tls/libc-2.3.6.so) 92k: /lib/ld-2.3.6.so 1 917 2883 3021 3027 3038 3039 3042 3049 3050 3051 3052 3053 3088 3096 3104 3108 3112 3127 3176 3183 3189 3248 3262 3268 3281 3282 3283 3284 3285 3286 3304 3320 3323 3353 3354 3359 3362 3363 3369 3373 3375 3377 3382 3383 3385 3389 3391 3393 3395 3396 3397 3398 3402 3403 3404 3405 3406 3407 3409 3418 3434 3471 3667 3668 4463 4550 4848 4849 1240k: /lib/tls/libc-2.3.6.so 1 917 2883 3021 3027 3038 3039 3042 3049 3050 3051 3052 3053 3088 3096 3104 3108 3112 3127 3176 3183 3189 3248 3262 3268 3281 3282 3283 3284 3285 3286 3304 3320 3323 3353 3354 3359 3362 3363 3369 3373 3375 3377 3382 3383 3385 3389 3391 3393 3395 3396 3397 3398 3402 3403 3404 3405 3406 3407 3409 3418 3434 3471 3667 3668 4463 4550 4848 4849 16k: /sbin/getty 3282 3283 3284 3285 3286

256+92+1240+16 будет 1604 > 1600

Я их читал. Лишний раз сейчас заглянул, но не нашел ответа на мой вопрос. Если не сложно, то можно меня в конкретные строки ткнуть?

Согласно описанию memstat-tutorial.txt.gz сумма должна совпадать.

Блин, сейчас на их примере про getty посмотрел - тоже не сходится, но в другую сторону.

ps aux |grep 3282
root 3282 0.0 0.0 1600 500 tty2 Ss+ 12:55 0:00 /sbin/getty 38400 tty2

% memstat -w |grep 3282
256k: PID 3282 (/lib/tls/libc-2.3.6.so)
92k: /lib/ld-2.3.6.so 1 917 2883 3021 3027 3038 3039 3042 3049 3050 3051 3052 3053 3088 3096 3104 3108 3112 3127 3176 3183 3189 3248 3262 3268 3281 3282 3283 3284 3285 3286 3304 3320 3323 3353 3354 3359 3362 3363 3369 3373 3375 3377 3382 3383 3385 3389 3391 3393 3395 3396 3397 3398 3402 3403 3404 3405 3406 3407 3409 3418 3434 3471 3667 3668 4463 4550 4848 4849
1240k: /lib/tls/libc-2.3.6.so 1 917 2883 3021 3027 3038 3039 3042 3049 3050 3051 3052 3053 3088 3096 3104 3108 3112 3127 3176 3183 3189 3248 3262 3268 3281 3282 3283 3284 3285 3286 3304 3320 3323 3353 3354 3359 3362 3363 3369 3373 3375 3377 3382 3383 3385 3389 3391 3393 3395 3396 3397 3398 3402 3403 3404 3405 3406 3407 3409 3418 3434 3471 3667 3668 4463 4550 4848 4849
16k: /sbin/getty 3282 3283 3284 3285 3286

256+92+1240+16 будет 1604 > 1600

>Я их читал. Лишний раз сейчас заглянул, но не нашел ответа на мой вопрос. Если не сложно, то можно меня в конкретные строки ткнуть?

>Согласно описанию memstat-tutorial.txt.gz сумма должна совпадать.

Видимо, имеется ввиду man memstat:

BUGS
       If you do the math, you’ll see that ps and memstat don’t always agree about how much virtual memory a process is using.  This is  because
       most processes seem to map certain shared pages twice.  memstat counts these pages once, ps counts them twice.  I’m not sure which is the
       ‘‘right’’ way to measure it.

       The proc filesystem identifies files by their device number and inode number.  To be useful, these numbers must be translated  back  into
       filenames.   This  requires  searching  the disk (and thus the awkward configuration file memstst.conf).  There should be some way around
       this, perhaps by adding the dev/inode info to the locate db?

       The stat system call returns a dev_t type, but the proc filesystem contains a device readout in the form of a string.  I have  improvised
       a routine to convert the device readout string into a dev_t, but I’m not sure it will work on all architectures.

       It  is  possible  to  confuse  memstat  by using mmap in combination with a block-device.  In the original version, memstat treated block
       devices just like any other file, and if you mmap’ed one of them, they would show up on the shared-object list.  This worked for  mmap’ed
       hard  disks  and  floppies, but it produced absurd results with block devices like /dev/zero and /dev/mem.  As a partial fix, memstat now
       ignores all mapped block devices, though this may cause memstat to ignore some memory usage.

       We really ought to show some real-memory usage statistics, but it’s just not there in /proc.

       Memory used by the kernel itself is not listed.

Спасибо большое, у меня реально что-то с глазами. :)