Проблема такая
Смотрю в top сразу после _запуска_ сервера - сумма всех колонок, показывающих память равна 3.4GB.
Потом видимая фрей память(сумма колонок в top) постепенно снижается
За неделю работы сервера - минус гигабайт. Т.е. сейчас например он у меня видит 2.4GB.
Потом он начинает свэппиться из-за недостатка ОП, и приходится его перезагружать. Что за фигня? Куда память течет?
ОС: FreeBsd 6.0
Сервер: 2 amd Optetron, мать tyan, памяти 4 гигабайта(по 2 гигабайта на процессор) (то, что 3.4 гигабайта видится(вместо четырех) - это вроде как нормально из-за того, что bios мэппит память от 3.4 до 4 GB под использование PCI)
К документации по FreeBSD 6.0 говорится не рекомендуется ставить 6.0 на реальные сервера, сам виноват
>К документации по FreeBSD 6.0 говорится не рекомендуется ставить 6.0 на реальные
>сервера, сам виноватДа, у меня есть подозрение относительно 6-й фрибсд.
Но вроде как это уже release..
Не могли бы вы дать конкретно место в документации, где не рекомендуется ставить?(просто интересно)Эксперты, ну что, никто с такой утечкой памяти не сталкивался? Существуют ли какие-нибудь способы диагностирования проблемы, чтобы понять, в чем - в ядре, в драйверах или в аппаратуре ошибка?
>К документации по FreeBSD 6.0 говорится не рекомендуется ставить 6.0 на реальные
>сервера, сам виноватэто где такое написано - ссылку в студию.
про утечку памяти и распределение по 2GB на каждый процессор :)
читать:- статью Метью Дилана о распределении памяти во FreeBSD
- или попробовать PAE (man PAE)в остальном, как уже было сказано - искать ЧТО использует и отжирает
память и возможно, почему держит или не освобождает
искать процессы, которые ее под себя гребут. У меня помниться perl выделывался.
>искать процессы, которые ее под себя гребут. У меня помниться perl выделывался.
>
Ребят, здесь не в процессах дело.
Здесь дело в ФИЗИЧЕСКИ ДОСТУПНОЙ ПАМЯТИ, КОТОРУЮ ВИДИТ ОС.
объем этой памяти уменьшается. (Посмотрите пожалуйста внимательно на мое первое сообщение)
Проблема здесь на уровне ядра.Я делал замеры каждые 10 минут. Получилось, что каждый час физичеки доступная память уменьшается на примерно 30 мегабайтов. Т.е. скачков никаких нет(типа раз в день отнялось 200 мегабайтов) - память течет постепенно. Что думаете?
>>искать процессы, которые ее под себя гребут. У меня помниться perl выделывался.
>>
>
>
>Ребят, здесь не в процессах дело.
>Здесь дело в ФИЗИЧЕСКИ ДОСТУПНОЙ ПАМЯТИ, КОТОРУЮ ВИДИТ ОС.
>объем этой памяти уменьшается. (Посмотрите пожалуйста внимательно на мое первое сообщение)
>Проблема здесь на уровне ядра.
>
>Я делал замеры каждые 10 минут. Получилось, что каждый час физичеки доступная
>память уменьшается на примерно 30 мегабайтов. Т.е. скачков никаких нет(типа раз
>в день отнялось 200 мегабайтов) - память течет постепенно. Что думаете?
>
# sysctl -a | grep hw.physmem
# sysctl -a | grep hw.realmem# sysctl -a | grep hw.*mem
ну и далее смотреть внимательно параметры ядра, ну скажем на примере
LINT'а:
options MAXDSIZ=(1024UL*1024*1024)
options MAXSSIZ=(128UL*1024*1024)
options DFLDSIZ=(1024UL*1024*1024)
или /sys/conf/NOTEShttp://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/co...
еще лучше поиск по спискам рассылки tuning kernel, mysql perfomance,
maxdsiz 4GB, pae... + man tuning
Привожу результаты мониторинга сервера, на котором уменьшается физически доступная память.
Итак, FreeBSD 6, 2xAmd64, 4 гига оперативки
Что работало на сервере в момент мониторинга: mysql 4 + apache1.3 (многопоточный aolserver я специально выключил для мониторинга)
Методика: раз в минуту запускается скрипт, который считает суммарный объем памяти по результатам вывода утилиты top и сует их в log-файлВот картина(вторая колонка - суммарный объем памяти по top):
маленькие флюктуации "плюс-минус 1 мегабайт) - это из-за округления
----
Sat Jan 7 20:37:00 MSK 2006 3224
Sat Jan 7 20:38:00 MSK 2006 3224
Sat Jan 7 20:39:00 MSK 2006 3224
Sat Jan 7 20:40:00 MSK 2006 3225
Sat Jan 7 20:41:00 MSK 2006 3223
Sat Jan 7 20:42:00 MSK 2006 3224
Sat Jan 7 20:43:00 MSK 2006 3222
Sat Jan 7 20:44:00 MSK 2006 3223
Sat Jan 7 20:45:00 MSK 2006 3221
Sat Jan 7 20:46:00 MSK 2006 3218
Sat Jan 7 20:47:00 MSK 2006 3217
Sat Jan 7 20:48:00 MSK 2006 3218
Sat Jan 7 20:49:00 MSK 2006 3213
Sat Jan 7 20:50:00 MSK 2006 3212
Sat Jan 7 20:51:00 MSK 2006 3212
Sat Jan 7 20:52:00 MSK 2006 3212
Sat Jan 7 20:53:00 MSK 2006 3211
Sat Jan 7 20:54:00 MSK 2006 3211
Sat Jan 7 20:55:00 MSK 2006 3210
Sat Jan 7 20:56:00 MSK 2006 3211
Sat Jan 7 20:57:00 MSK 2006 3209
Sat Jan 7 20:58:00 MSK 2006 3211
Sat Jan 7 20:59:00 MSK 2006 3210
Sat Jan 7 21:00:00 MSK 2006 3209
Sat Jan 7 21:01:00 MSK 2006 3208
Sat Jan 7 21:02:00 MSK 2006 3207
Sat Jan 7 21:03:00 MSK 2006 3205
Sat Jan 7 21:04:00 MSK 2006 3206
Sat Jan 7 21:05:00 MSK 2006 3206
Sat Jan 7 21:06:00 MSK 2006 3204
Sat Jan 7 21:07:00 MSK 2006 3203
Sat Jan 7 21:08:00 MSK 2006 3204
Sat Jan 7 21:09:00 MSK 2006 3202
Sat Jan 7 21:10:00 MSK 2006 3202
Sat Jan 7 21:11:00 MSK 2006 3204
Sat Jan 7 21:12:00 MSK 2006 3203
Sat Jan 7 21:13:00 MSK 2006 3203
Sat Jan 7 21:14:00 MSK 2006 3203
Sat Jan 7 21:15:00 MSK 2006 3202
Sat Jan 7 21:16:00 MSK 2006 3202
Sat Jan 7 21:17:00 MSK 2006 3202
Sat Jan 7 21:18:00 MSK 2006 3201
Sat Jan 7 21:19:00 MSK 2006 3201
Sat Jan 7 21:20:00 MSK 2006 3201
Sat Jan 7 21:21:00 MSK 2006 3202
Sat Jan 7 21:22:00 MSK 2006 3201
Sat Jan 7 21:23:00 MSK 2006 3200
Sat Jan 7 21:24:00 MSK 2006 3203
Sat Jan 7 21:25:00 MSK 2006 3202
Sat Jan 7 21:26:00 MSK 2006 3201
Sat Jan 7 21:27:00 MSK 2006 3203
Sat Jan 7 21:28:00 MSK 2006 3203
Sat Jan 7 21:29:00 MSK 2006 3203
Sat Jan 7 21:30:00 MSK 2006 3202
Sat Jan 7 21:31:00 MSK 2006 3203
Sat Jan 7 21:32:00 MSK 2006 3203
Sat Jan 7 21:33:00 MSK 2006 3202
Sat Jan 7 21:34:00 MSK 2006 3202
Sat Jan 7 21:35:00 MSK 2006 3201
Sat Jan 7 21:36:00 MSK 2006 3201
Sat Jan 7 21:37:00 MSK 2006 3201
Sat Jan 7 21:38:00 MSK 2006 3200
Sat Jan 7 21:39:00 MSK 2006 3201
Sat Jan 7 21:40:00 MSK 2006 3199
Sat Jan 7 21:41:00 MSK 2006 3201
Sat Jan 7 21:42:01 MSK 2006 3201
Sat Jan 7 21:43:00 MSK 2006 3200
Sat Jan 7 21:44:00 MSK 2006 3200
Sat Jan 7 21:45:00 MSK 2006 3200
Sat Jan 7 21:46:00 MSK 2006 3200
Sat Jan 7 21:47:00 MSK 2006 3199
Sat Jan 7 21:48:00 MSK 2006 3199
Sat Jan 7 21:49:00 MSK 2006 3199
Sat Jan 7 21:50:00 MSK 2006 3198.544
Sat Jan 7 21:51:00 MSK 2006 3199
Sat Jan 7 21:52:00 MSK 2006 3199
Sat Jan 7 21:53:00 MSK 2006 3198
Sat Jan 7 21:54:00 MSK 2006 3197
Sat Jan 7 21:55:00 MSK 2006 3198
Sat Jan 7 21:56:00 MSK 2006 3197
Sat Jan 7 21:57:00 MSK 2006 3198
Sat Jan 7 21:58:00 MSK 2006 3197
Sat Jan 7 21:59:00 MSK 2006 3197
Sat Jan 7 22:00:00 MSK 2006 3198
Sat Jan 7 22:01:00 MSK 2006 3197
Sat Jan 7 22:02:00 MSK 2006 3197
Sat Jan 7 22:03:00 MSK 2006 3197
Sat Jan 7 22:04:00 MSK 2006 3196
Sat Jan 7 22:05:00 MSK 2006 3196
Sat Jan 7 22:06:00 MSK 2006 3195
Sat Jan 7 22:07:00 MSK 2006 3195.62
Sat Jan 7 22:08:00 MSK 2006 3196
Sat Jan 7 22:09:00 MSK 2006 3196
Sat Jan 7 22:10:00 MSK 2006 3196
Sat Jan 7 22:11:00 MSK 2006 3194
Sat Jan 7 22:12:00 MSK 2006 3195
Sat Jan 7 22:13:00 MSK 2006 3196
Sat Jan 7 22:14:00 MSK 2006 3195
Sat Jan 7 22:14:00 MSK 2006 3195
-----Сразу после загрузки эта сумма равна 3405(что правильно)
А вот вывод sysctl:
hw.physmem: 3478589440
hw.realmem: 3488743424
Эти числа __не меняются__ со временемВопрос номер 1.
Откуда берет информацию о памяти утилита top? что является первоисточником для нее?Вопрос номер 2.
Почему hw.physmem показывает правильные значения, а по top память утекает?Вопрос номер 3.
Может ли криво написанное приложение оказывать влияние на ядро ОС? По идее, фундаментальным требованием к ОС является то, что ядро полностью защищено от приложений пользовательского уровня, т.е. никакое приложение пользовательского уровня, как бы криво оно написано не было, никоим образом не может влиять на ядро(и уж тем более на память, видимую им)
Это утверждение верно? Если да, то проблема либо в ядре, либо в хардваре.Вопрос номер 4.
Что делать дальше?
>Вопрос номер 4.
>Что делать дальше?Попробовать поставить память менее 4 Giga и посмотреть на утечки