|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Anton Shuko 2:5005/66 19 Jun 2007 22:56:25
To : Alex Mizrahi
Subject : memory usage
--------------------------------------------------------------------------------
18 Jun 07 22:12, you wrote to All:
AM> From: "Alex Mizrahi" <udodenko@users.sourceforge.net>
AM> helo
AM> наткнулся на странности с выделением памяти..
AM> есть виртуальная машина (vmware), на которой из крупных процессов
AM> крутится только сервер на Java. этому серверу в настройках Java
AM> отведено 220 MB памяти. всей виртуальной машине я отвёл 256 MB -- т.е.
AM> остальным процессам и на другие накладные расходы остаётся 36
AM> MB. причём на всякий случай я ему включил swap.
AM> как оказалось, при обращении к серверу Java оно начинает активно
AM> свопиться, т.е. памяти ей не хватает. причём, по-идее вся резидентная
AM> память Java не нужна (кроме как для full gc), но во всё равно
AM> свопится, зараза.
AM> данные top:
AM> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
AM> 2935 tomcat5 25 0 462m 227m 3744 S 0.0 90.7 4:15.08 java
AM> 3020 www-data 20 0 226m 1108 724 S 0.0 0.4 0:00.12 apache2
AM> free:
AM> total used free shared buffers
AM> cached Mem: 256972 253116 3856 0 340
AM> 7456 -/+ buffers/cache: 245320 11652 Swap: 409616
AM> 148696 260920
AM> сессия своппинга, запечатленная vmstat 5:
AM> procs -----------memory---------- ---swap-- -----io---- -system--
AM> -+--cpu---- 0 0 153576 3912 360 6612 0 0 0 0
AM> 251 42 0 0 100 0 0 0 157532 5088 464 7936 35 963 450
AM> 997 293 89 0 5 83 12 0 3 172720 3120 316 7768 3910 3061
AM> 3926 3083 1210 128 27 53 11 9 1 1 188416 3128 44 4636 6808
AM> 3564 6808 3570 1966 201 2 81 0 17 1 1 199512 3568 56
AM> 2532 3898 3092 4090 3092 1271 203 8 54 0 38 1 1 204808 3660
AM> 84 4800 2951 2254 3856 2254 1029 210 18 43 0 39 1 0 205264
AM> 4236 52 3112 2710 1831 2915 1834 977 172 25 44 0 31 1 1
AM> 204808 3368 72 2996 370 162 454 162 349 66 86 13 0 1
AM> 0 0 205700 4248 124 5032 189 570 846 577 319 127 62
AM> 10 11 17 1 0 205652 4148 128 5040 22 0 29 0 252
AM> 42 0 0 100 0 1 0 205652 4156 136 5044 0 0 0 2
AM> 251 43 0 0 100 0
AM> т.е свопилось оно примерно 6 x 5 = 30 секунд, со средней
AM> интенсивонстью порядка 3х мегабайт в секунду на ввод и вывод.. т.е.
AM> прокачало по 90 мегабайт в обоих направлениях..
AM> распечатка /proc/meminfo:
AM> MemTotal: 256972 kB
AM> MemFree: 4724 kB
AM> Buffers: 972 kB
AM> Cached: 9888 kB
AM> SwapCached: 155632 kB
AM> Active: 179180 kB
AM> Inactive: 64100 kB
AM> HighTotal: 0 kB
AM> HighFree: 0 kB
AM> LowTotal: 256972 kB
AM> LowFree: 4724 kB
AM> SwapTotal: 409616 kB
AM> SwapFree: 203240 kB
AM> Dirty: 4 kB
AM> Writeback: 0 kB
AM> AnonPages: 229404 kB
AM> Mapped: 3164 kB
AM> Slab: 5060 kB
AM> PageTables: 908 kB
AM> NFS_Unstable: 0 kB
AM> Bounce: 0 kB
AM> CommitLimit: 538100 kB
AM> Committed_AS: 777796 kB
AM> VmallocTotal: 770040 kB
AM> VmallocUsed: 2552 kB
AM> VmallocChunk: 766908 kB
AM> вот тут непонятно.. куча страниц в SwapCached..
AM> AnonPages как раз как и прогнозировалось -- 230 MB. по остальным
AM> статьям тоже вроде бы особых расходов не наблюдается, так что не
AM> понятно, зачем нужно скидывать 150 MB в swap, а потом прокачивать 100
AM> MB из него..
AM> я предположил, что просто алгоритмы выделения памяти просто не
AM> оптимизированы под случай когда память забита под завязку.
AM> но отключить swap оно не даёт! если же убить сервер Java, освободив
AM> память и отключить swap, то при загрузке сервера он со временем
AM> вылетает из-за нехватки памяти. т.е. памяти действительно не хватает,
AM> но как узнать сколько именно?
AM> на самом деле не то, чтобы это было мне сейчас особо важно -- я могу
AM> просто выделить виртуальной машине побольше памяти. но интересно
AM> разобраться, каким образом Linux расчитывает объёмы памяти, где
AM> скрываются "неучтённые" расходы. может в /proc есть какая-то более
AM> детальная информация? просто в будущем у меня, вероятно, увеличатся
AM> объёмы данных, и хотелось бы знать, на что я могу расчитывать. как
AM> оказалось, не стоит доверять данным RES в top..
AM> кстати, если убить процесс Java, то данные free выглядят так:
AM> debian:/proc# free
AM> total used free shared buffers
AM> cached Mem: 256972 42024 214948 0 3148
AM> 28952 -/+ buffers/cache: 9924 247048 Swap: 409616
AM> 5640 403976
AM> т.е. жрёт память, похоже, именно он.
AM> на всякий случай версия Linux -- Debian 4.0, kernel 2.6.18-4-686
ява да еще с кучей тредов жрет память так что крышу сносит всем измерялкам.
единственно что free показывает честный остаток и то не всегда. а если бы ты
поюзал sybase то там вообще туши свет: free кажет 30-40 мег занято и остальное
свободно, хотя базе выделил полтора гига и она ее активно заюзала...
самому интересно, чем смотреть расход памяти с подобным софтом.
Anton
--- GoldED/W32 3.0.1
* Origin: Пиво пить - здоровым быть !!! (2:5005/66)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
