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