free/top показывает направильный размер памяти

Данные top в принципе могут оказаться неправильными. пруф

Это известно и хорошо задокументировано НО НЕВЕРНО!. sysv shared memory как раз оказывается внутри cached. Вот пример

[root@vr-t500 include]# free -m
             total       used       free     shared    buffers     cached
Mem:          7917       4208       3708          0        212       1380
-/+ buffers/cache:       2615       5302
Swap:         5935          0       5935

[root@vr-t500 include]# ipcs -m -u

------ Shared Memory Status --------
segments allocated 73
pages allocated 187285
pages resident  31206
pages swapped   0
Swap performance: 0 attempts     0 successes

т.е. кажется, что занято всего 2.6 метра

Слепой или линуксоид?

Написано же used 4208

т.е. кажется, что занято всего 2.6 метра
-/+ buffers/cache: 2615

2615 «метров»

Оказывается, free или top при показе свободной памяти не показывает память занимаемую объектами sys v (семафоры, очередеи, shared memory).

о да. Тег ВНЕЗАПНО забыл.

да конечно

А где это задокументировано? под «это» подразумевается, что то что называется «cache», на самом деле может быть совсем не кешем, а shared memory?

https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt

Since tmpfs lives completely in the page cache and on swap, all tmpfs pages currently in memory will show up as cached. It will not show up as shared or something like that.

А про sysv? Она живет не в tmps

Давайте я Вам скопипастю из Documentation/filesystems/tmpfs.txt:

1) There is always a kernel internal mount which you will not see at all. This is used for shared anonymous mappings and SYSV shared memory.

This mount does not depend on CONFIG_TMPFS. If CONFIG_TMPFS is not set, the user visible part of tmpfs is not build. But the internal mechanisms are always present.

Удивительно что этого нет в манах по free, top итд. Т.е. если предположить, что дока делится на часть предназначенную обычным пользователям, и на часть для разработчиков, то казалось бы это должно быть описано в части для обычных пользователей.

Не то что бы неправильный, но однозначно непонятный. Вот есть к примеру прога которая работает с shared памятью

08/07/13-15:03:41:658 (0) 0 Allocated 1216MB shared memory

#free -m
             total       used       free     shared    buffers     cached
Mem:          8192       1730       6461          0          0        783
-/+ buffers/cache:        947       7244
Swap:         8192          0       8191

Почему shared нулевой ? Где тот shared который используется прогой ? в -/+, отлично блин ...

По это как раз мане написано The shared memory column should be ignored; it is obsolete.

IMXO идиотизм. Нафига выводить тогда ?

Для совместимости с древними утилитами, которые парсят этот вывод? Думаю, чтоит написать свою утилиту для получения нормальной информации. Пока мы встроили обработку этой несуразности в код мониторинга нашего приложения.

Совместимость™, ведь вывод free может использоваться в скриптах.

Совместимость™, ведь вывод free может использоваться в скриптах.

Причем в скрипты захордкодены позиции ? Я понимаю что, как говориться, текстовые пайпы это на всё - но ощущение костылизма ради костылизма на примере free никак не проходить

Для совместимости с древними утилитами, которые парсят этот вывод?

Если утилиты парсять именно значение shared то они уже бог знает сколько времени получают неверное значение.

Если они парсят к примеру cached как 7-е слово во второй строке, то почему бы всё таки не придать shared колонке смысл ? Ведь shared memory как таковая никуда не obsolete.

это проблема? или awk '{print}' уже костыль?

это проблема?

Если для этого придется «навечно» оставить колонку в выводе, и приписывать в мане - пожалуйста игнорируйте это поле, оно устарело - то да проблема.

Но как тут как в анекдоте. Не ПРОБЛЕМА! ПРОБЛЕМА! ПРОБЛЕМА! но .. проблема да

Выше уже описал что эту колонку логичнее возвратить к жизни, ибо самое понятие shared memory никуда не делось, чем оставлять зомби из 70x