Имеется SuSE SLES 9 SP1. Стоит он на серваке с 1 гигом памяти.
После загрузки через некоторое время занимается 850 метров оперативки. Кто сжирает память??? Среди запущеных процессов ничего прожорливого не нашел...
Подскажите, как разобраться???

Прикольный он пацан... А если мне нужно для oracle отрезать 400 метров памяти, что мне делать??? Сервак перегружать?? Или есть средство, как неиспользуемую память почистить?

И что, никто ничего подсказать не может???

g613 Алексей ФилипповИ что, никто ничего подсказать не может???

а как ты определил что он 850 метров скушал ?

top

lissyaraЕсли ораклу надо будет, он хлам и выкинет.
Posted via ActualForum NNTP Server 1.1

Oracle занимает 150 метров, всего занято 850(непонятно кем). Мне нужно дать ораклу еще 200 метров. Но оракл говорит, что дать я ему ничего не могу, так как у системы недостаточно свободной физической памяти. Вот я и интересуюсь - что делать???

Разници между top и free не заметил - цифры показывают одинаковые

> cat /proc/sys/kernel/shmmax
3294967296

А памяти вот как не может дать:

SQL> alter system set db_cache_size=120M scope=both;
alter system set db_cache_size=120M scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00384: Insufficient memory to grow cache

Нет. Если ругается на синтаксис, то и говорит, что проблеммы с синтаксисом(хотя возможны варианты). Данная команда указывает, что поменять нужно прямо сейчас, + занести в файл параметров. Если в этой команде указать scope=spfile, то есть записать в файл параметров но сейчас не менять, то отрабатывает нормально. Перегружаешь базу и все чики-чики. Но мне нужно на лету.

g613если top и free (там где -/+ buffers/cache ) показывают одинаковые цифры, то посмотри в том же top а что собственно за процесс скушал память.

Нету там такого :(

Кстати, щас объем использованой памяти упал до 520 метров... Ну тут можно сказать, что все нормально... Только я не понял ситуации с полностью съеденой оперативкой. Я тогда долго пытался найти процесс, который занимает столько памяти. Не нашел - думал руки корявые. Другие тоже поискали - не нашли...

Я вот щас заметил, что действительно оракл как-то криво пытается памать отгрести, может и с ним что-то не так, базару нет. Сейчас вот память освободилась, а ошибка осталась...

НО!

Если top и free показывают, что использовано 850М памяти, при этом сумма всей фактичекси используемой памяти процессами составляет ~200М - это ведь тоже ненормально.

Где правда???

Виноват, когда отвечал - предыдущее сообщение еще не видел. Если так, то возможно, проблема действительно в оракле

FREE:

total used free shared buffers cached
Mem: 1034284 538564 495720 0 20052 459388
-/+ buffers/cache: 59124 975160
Swap: 2104472 0 2104472

TOP:

top - 15:55:55 up 7:50, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 62 total, 1 running, 61 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0% us, 0.0% sy, 0.0% ni, 99.7% id, 0.2% wa, 0.0% hi, 0.2% si
Mem: 1034284k total, 538896k used, 495388k free, 20284k buffers
Swap: 2104472k total, 0k used, 2104472k free, 459156k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 16 0 588 244 208 S 0.0 0.0 0:05.71 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/1
5 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
6 root 5 -10 0 0 0 S 0.0 0.0 0:00.02 events/0
7 root 5 -10 0 0 0 S 0.0 0.0 0:00.04 events/1
8 root 15 -10 0 0 0 S 0.0 0.0 0:00.00 kacpid
9 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 kblockd/0
10 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 kblockd/1
11 root 15 0 0 0 0 S 0.0 0.0 0:00.00 kirqd
14 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 khelper
15 root 15 0 0 0 0 S 0.0 0.0 0:00.47 pdflush
16 root 15 0 0 0 0 S 0.0 0.0 0:00.72 pdflush
18 root 13 -10 0 0 0 S 0.0 0.0 0:00.00 aio/0
17 root 15 0 0 0 0 S 0.0 0.0 0:00.75 kswapd0
19 root 14 -10 0 0 0 S 0.0 0.0 0:00.00 aio/1
679 root 25 0 0 0 0 S 0.0 0.0 0:00.10 kseriod
723 root 22 0 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_0
1010 root 15 0 0 0 0 S 0.0 0.0 0:00.26 kjournald
...

g613 Алексей Филиппов FREE:

total used free shared buffers cached
Mem: 1034284 538564 495720 0 20052 459388
-/+ buffers/cache: 59124 975160
Swap: 2104472 0 2104472



дык и 60 метров не сьели... а ты гриш 500..

_НЕ_ смотри на 538564б смотри на 59124...

то есть с памятью у тебя все нормально... :)

Надо маны по free почитать. А пока не почитал, замечу, что ты что-то путаешь... У меня там щас oracle работает, который 320 отхавал под себя точно. Так что 59124 это не то, на что нужно смотреть, чтоб определить загрузку...

Мда, вижу, что проблема несколько непонятна... Объясняю:
1. SuSE загрузился, занял 160М
2. Через 2 часа память заняла 850М. В это время я поднимал и останавливал оракл, еще там всякое разное с ораклом связанное делал, короче работал. В итоге оракл выключен (он требует 320М), а памяти занято 850М
3. Поднимаю оракл с занятыми 850М оперативки, он забирает себе 320М(эту величину я смотрел внутренними средствами оракл), при этом количество скушаной памяти возрастаем до 900М... Прикольно :)
4. Ночь сервак стоит... В итоге утром и top и free показывают, что занято 250М(!!!!!) памяти. Это с учетом того, что оракл никто не выключал - база работает и занимает все так же 320М в SGA.... Я хренею...

Короче, насколько я понял SuSE SLES9 как-то по хитрому работает с памятью. С этим и надо разбираться...