FreeBsd 6.0 постепенно уменьшается доступная память

ilyaver · Сообщение **ilyaver** » 06 янв 2006, 14:29

Проблема такая
Смотрю в top сразу после _запуска_ сервера - сумма всех колонок, показывающих память равна 3.4GB.
Потом видимая фрей память(сумма колонок) постепенно снижается
За неделю работы сервера - минус гигабайт. Потом он начинает свэппиться из-за недостатка ОП, и приходится его перезагружать. Что за фигня? Куда память течет?
ОС: FreeBsd 6.0
Сервер: 2 amd Optetron, мать tyan, памяти 4 гигабайта(по 2 гигабайта на процессор) (то, что 3.4 гигабайта видится - это вроде как нормально из-за того, что bios мэппит память от 3.4 до 4 GB под использование PCI)

ilyaver · Сообщение **ilyaver** » 07 янв 2006, 18:58

Апдейт проблемы.
Делал замеры каждые 10 минут. Оказалось, что память утекает не болшими скачками, а равномерно.
Выяснилось, что за каждый час уходит в среднем 30 мегабайтов.
Что скажете?

brj · Сообщение **brj** » 07 янв 2006, 22:29

Текет по тредам какое-то приложение скорее всего.

ilyaver · Сообщение **ilyaver** » 07 янв 2006, 22:44

Привожу результаты мониторинга сервера, на котором уменьшается физически доступная память.
Итак, 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.
Что делать дальше?

ilyaver · Сообщение **ilyaver** » 07 янв 2006, 22:46

brj писал(а):Текет по тредам какое-то приложение скорее всего.

Посмотрите пожалуйста вопрос 3 в предыдущем посте. Что на это можете сказать?
PS. Из многопоточных приложений в период набора вышеприведенной статистики на сервере крутился только mysql 4.

brj · Сообщение **brj** » 07 янв 2006, 23:07

Ну возьмем мою домашнюю машину. Гиг памяти и гиг свопа, аптайм 32 дня.

last pid: 76814; load averages: 0.08, 0.02, 0.01 up 32+01:15:32 03:01:13
98 processes: 1 running, 97 sleeping
CPU states: 2.3% user, 0.0% nice, 3.9% system, 0.9% interrupt, 92.9% idle
Mem: 77M Active, 699M Inact, 168M Wired, 45M Cache, 111M Buf, 5760K Free
Swap: 1024M Total, 96K Used, 1024M Free

77 мегабайт занято процессами.
669 мегебайт "закешированно" и освободится по первому требованию другого приложения.
168 мегабайт память которую нельзя свопить.
45 мегебайт в кеше
111 мегабайт буфер
5 мег свободно.

man 1 top
amn 4 mem

Что не понятно?

ilyaver · Сообщение **ilyaver** » 07 янв 2006, 23:16

brj писал(а): Что не понятно?

Не понятно, почему у меня объем доступной памяти постоянно уменьшается

brj · Сообщение **brj** » 07 янв 2006, 23:43

Доступная эта какая из 6ти? 8)

ilyaver · Сообщение **ilyaver** » 08 янв 2006, 00:50

brj писал(а):Доступная эта какая из 6ти? 8)

Доступная для ОС память - сумма всех 6ти.
В первом моем сообщении об этом написано.

brj · Сообщение **brj** » 08 янв 2006, 08:17

А можно мне шел? Я хочу на это посмотреть. :roll:

Сообщение **Stranger03** » 10 янв 2006, 10:24

ilyaver писал(а):Доступная для ОС память - сумма всех 6ти.
В первом моем сообщении об этом написано.

У меня была похожая проблемка на 4.4, некий демон пытался записать логи, но вместо сброса их на диск он почему-то исправно копил в памяти (кстати kavdaemon). Посмотрите статистику по демонам.

Andrey N. Oktyabrski

ilyaver писал(а):Привожу результаты мониторинга сервера, на котором уменьшается физически доступная память.
Итак, FreeBSD 6, 2xAmd64, 4 гига оперативки
Что работало на сервере в момент мониторинга: mysql 4 + apache1.3 (многопоточный aolserver я специально выключил для мониторинга)

А можно поточнее версии? Самой ОС, мускула (4.0 и 4.1 - "это две большие разницы") и всего остального, что там работает.

Вопрос номер 1.
Откуда берет информацию о памяти утилита top? что является первоисточником для нее?

Вообще-то показаниями топа, особенно во фре, пользоваться трудно. Он, например, частенько у меня показывает загрузку процессора >100%.

Вопрос номер 2.
Почему hw.physmem показывает правильные значения, а по top память утекает?

Потому что hw.physmem устанавливается один раз при загрузке и потом никогда не меняется до следующей перезагрузки. Это именно объём физической памяти в машине.

Вопрос номер 3.
Может ли криво написанное приложение оказывать влияние на ядро ОС? По идее, фундаментальным требованием к ОС является то, что ядро полностью защищено от приложений пользовательского уровня, т.е. никакое приложение пользовательского уровня, как бы криво оно написано не было, никоим образом не может влиять на ядро(и уж тем более на память, видимую им)
Это утверждение верно? Если да, то проблема либо в ядре, либо в хардваре.

Теоретически да. Только проблема совершенно точно не в железе при описанных симптомах.

Вопрос номер 4.
Что делать дальше?

Послать к такой-то матери эту @#$%^&*ю фрю и перелезть на солярку. Качество фри не поддаётся никакой критике. Я ей пользуюсь с версии 2.2.1 и хорошо помню те времена, когда она была надёжной системой. То, что сейчас с ней сделали, работает гораздо хуже пингвинов. А снапшоты OpenSolaris (-current в терминологии freebsd) работают гораздо более устойчиво и предсказуемо, чем все -release & -stable freebsd.

smb- · Сообщение **smb-** » 12 янв 2006, 22:20

Послать к такой-то матери эту @#$%^&*ю фрю и перелезть на солярку. Качество фри не поддаётся никакой критике. Я ей пользуюсь с версии 2.2.1 и хорошо помню те времена, когда она была надёжной системой. То, что сейчас с ней сделали, работает гораздо хуже пингвинов. А снапшоты OpenSolaris (-current в терминологии freebsd) работают гораздо более устойчиво и предсказуемо, чем все -release & -stable freebsd.

Дык еще бы - текущие версии фряхи далеко не для серверов...И уж юзать 6.0 для production - это лучше сразу стреляться....Имхо - 4.11 очень даже стабильная штука...

Насколько я помню сорцы топа, он берет инфу из ядра через системные вызовы навроде getkernparam() (за точное название не ручаюсь...) - поэтому показания нормальные(по крайней мере, по памяти)

Andrey N. Oktyabrski

smb- писал(а):
Послать к такой-то матери эту @#$%^&*ю фрю и перелезть на солярку. Качество фри не поддаётся никакой критике. Я ей пользуюсь с версии 2.2.1 и хорошо помню те времена, когда она была надёжной системой. То, что сейчас с ней сделали, работает гораздо хуже пингвинов. А снапшоты OpenSolaris (-current в терминологии freebsd) работают гораздо более устойчиво и предсказуемо, чем все -release & -stable freebsd.
Дык еще бы - текущие версии фряхи далеко не для серверов...И уж юзать 6.0 для production - это лучше сразу стреляться....Имхо - 4.11 очень даже стабильная штука...

Стреляться не надо, это не наш путь :-) Если её удалось заставить работать, она работает хорошо. Только вот заставить её работать всё труднее :-(

Насколько я помню сорцы топа, он берет инфу из ядра через системные вызовы навроде getkernparam() (за точное название не ручаюсь...) - поэтому показания нормальные(по крайней мере, по памяти)

brj · Сообщение **brj** » 14 янв 2006, 20:53

rambler работает на 6.x и CARP. Ничего так... :?

FreeBsd 6.0 постепенно уменьшается доступная память

FreeBsd 6.0 постепенно уменьшается доступная память

Кто сейчас на конференции