LINUX.ORG.RU

Oracle 8.1.7, Suse Linux 9.1, Kernel 2.6.13.4, тормоза дисковой подсистемы


0

0

Доброго времени суток. Сервер: 2*Xeon 3Ггц, 4Gb RAM, 6*HDD SCSI 320. Всё это работает на Intel RAID SRCU42X(LSI Logic MegaRAID) 256 мб. На контроллере два канала. Две карзины. RAID 1. Диски расположены так, чтобы один массив из двух дисков был на разных каналах SCSI контроллера. Система Suse Linux 9.1 kernel 2.6.13.4, Oracle 8.1.7. Регулярно наблюдаются тормоза оракла или самой системы, как я уже подозреваю. Load average доходит до 10-15. Загрузка по top выглядит примерно таким образом:

top - 17:01:05 up 21 days, 15:09, 3 users, load average: 3.09, 3.55, 3.13 Tasks: 341 total, 2 running, 339 sleeping, 0 stopped, 0 zombie Cpu0 : 30.3% us, 3.0% sy, 0.0% ni, 26.3% id, 40.3% wa, 0.0% hi, 0.0% si Cpu1 : 17.8% us, 0.7% sy, 0.0% ni, 77.6% id, 3.6% wa, 0.0% hi, 0.3% si Cpu2 : 37.7% us, 2.0% sy, 0.0% ni, 35.1% id, 24.5% wa, 0.3% hi, 0.3% si Cpu3 : 4.7% us, 0.0% sy, 0.0% ni, 78.4% id, 16.9% wa, 0.0% hi, 0.0% si Mem: 4151228k total, 4015688k used, 135540k free, 18988k buffers Swap: 4200956k total, 2020k used, 4198936k free, 2696172k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23401 oracle 15 0 1752m 666m 662m S 27.5 16.4 3:03.79 oracleibso (DESCRI 6773 oracle 18 0 1749m 224m 222m D 14.6 5.5 0:21.88 oracleibso (DESCRI 24834 oracle 16 0 1752m 388m 383m S 11.6 9.6 0:28.61 oracleibso (DESCRI

из всего этого меня беспокоит то, что часто бывает ожидания дисковой подсистемы, т.е. что и видно из результатов top. Может быть кто-то сталкивался с подобной проблемой или тормозами на LSI MegaRAID?

Сомневаюсь, но может быть помогут параметры ядра:

kernel.shmall=2097152 kernel.shmmax=2147483648 kernel.shmmni=4096 kernel.sem=250 32000 100 128 fs.file-max=65536 net.ipv4.ip_local_port_range=1024 65000 vm.disable_cap_mlock=1

Спасибо.


Ответ на: комментарий от gr_buza

top - 17:01:05 up 21 days, 15:09, 3 users, load average: 3.09, 3.55, 3.13
Tasks: 341 total, 2 running, 339 sleeping, 0 stopped, 0 zombie
Cpu0 : 30.3% us, 3.0% sy, 0.0% ni, 26.3% id, 40.3% wa, 0.0% hi, 0.0% si
Cpu1 : 17.8% us, 0.7% sy, 0.0% ni, 77.6% id, 3.6% wa, 0.0% hi, 0.3% si
Cpu2 : 37.7% us, 2.0% sy, 0.0% ni, 35.1% id, 24.5% wa, 0.3% hi, 0.3% si
Cpu3 : 4.7% us, 0.0% sy, 0.0% ni, 78.4% id, 16.9% wa, 0.0% hi, 0.0% si
Mem: 4151228k total, 4015688k used, 135540k free, 18988k buffers
Swap: 4200956k total, 2020k used, 4198936k free, 2696172k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23401 oracle 15 0 1752m 666m 662m S 27.5 16.4 3:03.79 oracleibso (DESCRI
6773 oracle 18 0 1749m 224m 222m D 14.6 5.5 0:21.88 oracleibso (DESCRI
24834 oracle 16 0 1752m 388m 383m S 11.6 9.6 0:28.61 oracleibso (DESCRI

rmir
() автор топика
Ответ на: комментарий от rmir

kernel.shmall=2097152
kernel.shmmax=2147483648
kernel.shmmni=4096
kernel.sem=250 32000 100 128
fs.file-max=65536
net.ipv4.ip_local_port_range=1024 65000
vm.disable_cap_mlock=1

rmir
() автор топика
Ответ на: комментарий от gr_buza

В логах ничего нет. Админ БД говорит, что смотрит в Orcale Enterprise Manager. Health over view chart, там есть график показывающий некую операцию с названием: db file sequental read, на которую и уходит больше всего времени.

rmir
() автор топика
Ответ на: комментарий от rmir

ну это чтение файла БД.

думаю, что проблема именно в железе.

ты говоришь два диска из одного массива на разных шлейфах?

gr_buza ★★★★
()
Ответ на: комментарий от gr_buza

Да. Там две карзины. Для данных 6 дисков. И два на Hot Spare. Каждая карзина на отдельном канале. RAID состоит из двух дисков, которые висят на разных каналах.

rmir
() автор топика
Ответ на: комментарий от gr_buza

Физически на два канала.

Да по идеи сложно кинуть на один канал. Просто сервер находится уже в эксплуатации.

rmir
() автор топика
Ответ на: комментарий от gr_buza

Нет. Конечно в выходные, если напрячь начальство и со всеми договориться, то можно. Просто даст ли это реальную выгоду видимо не понятно. Там ведь потом будет заморочка с RAID'ом.

rmir
() автор топика

Зачем на серваке ядро пересобирать было? 2.6.4 чем не устраивало? Фиксы все через автоапдейт и так идут.

suser
()
Ответ на: комментарий от rmir

Кое, что выснилось. Оказывается оракл работал в синхронном режиме, т.е. файловая система по умолчанию как и всегда в асинхронном, а оракл тупил и не знал, что можно в асинхронном работать. Вопрос: в инете в основном пишут про 9 оракл, как в нём задействовать асинхронный режим, ну т.е. биб-ка libaio, libaio-oracle, make -f ins_rdbms.mk async_on и т.д. Актуально ли это для 8 оракла?

rmir
() автор топика
Ответ на: комментарий от rmir

В целом AIO практически одинаково включается и на 8i, и на 9i. Но тебе лучше посмотреть на количество так называемых I/O slaves, при этом не придется связываться с перелинковкой и всякими фенечками. Кроме того, я могу ошибаться, как мне кажется на 8i+Linux AIO включается только на raw-device'ах.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Спасибо большое. Инсталировал libaio и включился асинхронные режим, видимо он был уже слинкован. Чуть позже добавим и IO_SLAVES.

rmir
() автор топика
Ответ на: комментарий от rmir

> Инсталировал libaio и включился асинхронные режим, видимо он был уже слинкован

????

Вообще-то, без libaio он изначально не слинкуется с поддержкой асинхронного I/O, как гласят слухи. Может, вы просто libaio{=devel} поставили и перелинковали? :-) Ну да это неважно.

На самом деле, я бы на вашем месте посмотрел на какой FS у вас лежат датафайлы (если это Ext3/Reiser - то в лес, под это дело можно использовать только XFS или Ext2, причем на ядрах 2.4 только ext2), проверил tablespace'ы на предмет extent management local и сделал кучу других интересных проверок.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Да. Если честно я тоже как-то очень сильно удивился с какого перепуга он стал быстрее работать, если я только инсталил две rpm-ки, libaio и libaio-devel, до перелинковки ещё руки не дошли. А вот на счёт ФС, то там исключительно ext2. На счёт остального, спасибо, буду смотреть.

rmir
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.