|
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) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/185746785ff0.html, оценка из 5, голосов 10
|