ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Dmitry Budanov                       2:5052/4       28 Mar 2004  23:15:32
 To : Valentin Nechayev
 Subject : Re: oracle и swap
 -------------------------------------------------------------------------------- 
 

 >>> пытаюсь поднять Oracle 10g. возникла забавная ситуация:
 >>> 
 >>> Mem:   3948680K total,  3834260K used,   114420K free,    25584K buffers
 >>> Swap:  3212920K total,    78692K used,  3134228K free,  3631044K cached
 >>> 
 >>> PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 >>> 460 oracle    15   0 74064  71M 71828 R    38.8  1.8   0:36 oracle
 >>> 363 oracle     9   0 26744  11M 10176 S     3.1  0.2   0:03 oracle
 >>> ....
 >>> 
 >>> какого $$$$ oracle лезет в swap, когда памяти полно (3631044K cached)? и
 >>> как это лечить?
 > NG> В своп попадают любые страницы, которые долго не используются. В
 > NG> стандартной VM это можно отключить только одним способом: swapoff -a.
 > NG> Вожможно, в каких-то из альтернативных VM это не так, но вряд ли.
 > Дело даже не совсем в этом. Linux (вместе со всеми BSD и рядом других
 > систем) реализует unified VM mach'евского стиля, в котором и данные процессов
 > и кэш диска рассматриваются как кэш диска. И когда возникает необходимость
 > чего-то выставить из памяти на диск, данные процессов рассматриваются тут
 > наравне с кэшом диска.
 > Для ядер 2.2 - 2.4.ранние (не смотрел ещё, починили ли в последних) это
 > выливалось в неприятный эффект: при активной записи на диск данные работающих
 > процессов начинают высвопляться наравне с модифицированными блоками кэша
 > диска, вместо того, чтобы выходить только после дисковых блоков.
 > Hа вебхостинге получалось загонять этим систему в трэшинг любой запрошенной
 > глубины;((
 
 проблема в том что так себя ведет именно oracle, например dd ... bs=1G
 ... себя так не ведет, честно откусывает 1G от cached. sybase ведет себя
 подобно dd, но до указанного размера раздувается по мере необходимости.
 почему именно oracle ведет себя именно так? пробовал в разными размерами
 SGA, PGA, вплоть до минимальных - нифига, все равно в своп лезет :(
 пробовал SGA распологать в shm, не помогло. особенно странным выглядит
 активное импользование свопа при full-scan таблиц (судя по vmstat), с
 _диким_ торможением самой операции. что я делаю не так?
 
 wbr, Dmitry
 --- FIDOGATE 4.4.1-snp14
  * Origin: Black Beard (2:5052/4.0)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор