LINUX.ORG.RU

Oracle inside


0

0

Очень такая скромно требовательная к ресурсам СУБД. Обратите внимание на эффективное распределение памяти. :) Да, это не MySQL конечно, но MySQL'у зато есть куда расти. Опен-сурс форева ;)

>>> Просмотр (1024x768, 178 Kb)



Проверено: Demetrio ()

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

2zenkov * (*) (22.08.2004 6:47:22)
Pathologically Eclectic Rubbish Listing :-)

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

Вау, так слакваре, как винды?

anonymous
()

Итак, вниманию народа прилагается не скриншот, но show sga от Oracle на Linux. В принципе, variable size наращивается примерно до 1.3GB, а database buffers поднимаются примерно до 60GB (ну, на самом деле скорее всего где-то до 58-ми :-)) Добиться этого можно на любом ядре с поддержкой PAE (при условии правильной сборки :-)), и ядро RH enterprise для этого необязательно.

SQL*Plus: Release 9.2.0.1.0 - Production on Mon Aug 23 08:59:40 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

SQL> Connected.
SQL>
Total System Global Area 3490779136 bytes
Fixed Size 450560 bytes
Variable Size 134217728 bytes
Database Buffers 3355443200 bytes
Redo Buffers 667648 bytes
SQL> Disconnected from Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production

Как видно из картинки, SGA даже не более 2-х, а поболее 3GB.

P.S.: На самом деле, конечно, это гнусный trick от Oracle :-)

P.P.S.: стамп сделан на машинке с 512-ю MB оперативки :-))

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

> Помоему господа путают размер SGA и SHMMAX

Факт, путают :-) На объем разделяемой памяти (shared memory) действительно есть ограничение 2/4GB, а вот на SGA оно гораздо более слабое, и вывести SGA за эти границы можно "легко и непринужденно" :-)

no-dashi ★★★★★
()

1) Понравилось как оформлена панель с иконками - приятный перелив с голубоватого на белыйю. Красиво... 2) Где взять такую обоину?

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

Дык что это такое? trick от Оракле или еще что? ;) Насчет RH ядро необязательно- при тестинге на 2.6.7 под реальной нагрузкой сервер потихоньку начинает "отставать" скорость падает потихонку. stamp сделан на машине с 512М- а сколько свапа? Тут проблема не в том чтобы цифры были большие а чтобы это реально работало и не тормозило.

Ты маякни на аську поговорим по этому поводу.

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

kernel.shmmax=3000000000 на этой тачке. И насчет ядра- ты поставь ядро от RH задействуй ramfs и вот там SGA подними. Очь интересно.

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

Спасибо за ссылочку!

Ого!!! :-О На скриншоте я-то и не видел, что это пикачу, да еще такой...

php-coder ★★★★★
()
Ответ на: комментарий от just

> И насчет ядра- ты поставь ядро от RH задействуй ramfs и вот там SGA подними

В соответствии с редхатовскими whitepapers рекомендуется использовать mount -t shm. Кто этого не сделал - тот ССЗАД (Сам Себе Злобный Антропоморфный Дендромутант :-))

А насчет редхатовского ядра - в соответствии с документацией загрузил на RHEL'овском ядре на shmfs... Ты не поверишь но все работает, и цифры те же самые.

К чему я веду - а к тому, что если кто-то не умеет читать документацию, считает себя самым умным и огребает с этого проблемы с производительностью (а судя по показателям они у тебя есть), то это его собственные трудности, не находишь?

Ладно, если когда-нибудь пойдешь в оракловый и редхатовый саппорт (не приведя тебя боже), они тебя просветят о том, что разгребают только проблемы тех, кто правильно пользуется документацией :-)

P.S.: прочти notes'ы в исходниках rams и tmpfs (последняя лежит в mm/shmem.c) - тогда ты поймешь, почему не следует использовать ramfs :-)

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

ount -t shm ... у да, где уж нам доки почитать, там еще если что и chown oracle.dba /dev/shm надо ;)

> А насчет редхатовского ядра - в соответствии с документацией загрузил > на RHEL'овском ядре на shmfs... Ты не поверишь но все работает, и > цифры те же самые.

А можно скрин? ;) именно 4 гига памяти и тп? и оракл 9.2.5.0 Я незнаю что там насчет SGA на системах с <2Gb, но дальше я так понял начинается самое интересное и глючное ;)

notes'ы не спорю не читал, завтра посмотрю че там про ramfs. Сам Оракл, если я не ошибаюсь, не рекомендует использовать hugetlb ядро а юзать именно через ramfs.

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

> там еще если что и chown oracle.dba /dev/shm

Там, если ты заметил, стоит drwxrwxrwt, так что chown oracle:dba ничего не изменит. Ну и посмотрев http://www.redhat.com/whitepapers/rhel/OracleonLinux.pdf могу сказать - так там насчет chown ничего нет :-/

> А можно скрин? ;) именно 4 гига памяти и тп?

Памяти на полигоне не 4GB (а трогать боевую машину чтобы удовлетворить твое любопытство я не стану) - но зато 4.8GB swap, ядро под 64GB. Опробовано, как я говорил, на 2.6 и RHEL'овском, которое с той же разверткой под память - характеристики одинаковые, однако 2.6 побыстрее оказывается. Если хочешь - могу сделать на рабочей станции скрин с того конфига, результаты которого показывал.

> Я незнаю что там насчет SGA на системах с <2Gb, но дальше
> я так понял начинается самое интересное и глючное ;)

Да ничего там не начинается - опции 64GB/4GB влияют на глобальную работу VM, и глюки лезут в любой конфигурации.

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

В доке с металинка chown говорят надо и все такое. OracleonLinux.pdf если не ошибаюсь достаточно старый и касается только AS 2.1 а про 3 ничего там не сказано. Ты мож 2.1 ставил? Ядро под 64Gb- если не ошибаюсь это hugeTLB ядро, сам Оракл его рекомендует использоваться когда на машине больше 4 гиг памяти и опять же на металинке написано было что могут возникнуть немаленькие проблемы с производительностью. Мне просто интересно- ты пробуешь именно на AS3 upd 2 или чем-то другом?

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

> Ядро под 64Gb- если не ошибаюсь это hugeTLB ядро, сам Оракл его рекомендует использоваться когда на машине больше 4 гиг памяти

Вполне возможно. Но сборка 2.6 для 4GB-ядра также корректно отрабатывает приведенный мной расклад. И опять-же, та же самая интуиция, которая гласила что на rhel'овском 64GB-ядре все будет работать, гласит что на rhel'овском 4GB-ядре тоже все будет нормально :-)

Расслабься, RHEL был сертифицирован ораклом, все будет работать. Вся фишка 9-ки на больших объемах памяти заключается в том, что оракл на самом деле всегда работает в 4-х гигабайтном адресном пространстве, и суть всех этих 2GB/4GB/64GB всего лишь в организации механизмов работы ядерного VM, юзерспейса же они не касаются (а оракл, как ты наверное помнишь, чистейший юзерспейс :-)). Впрочем, для повышения эффективности работы оракла на huge-ядрах в том документе также были даны рекомендации.

> Мне просто интересно- ты пробуешь именно на AS3 upd 2 или чем-то другом?

2.4.21-9 это ну никак не двоечка, вопрос мимо кассы :-)

> OracleonLinux.pdf если не ошибаюсь достаточно старый и касается только AS 2.1 а про 3 ничего там не сказано.

Методика обхода ограничения в 4GB не меняется - она заложена не в ядре/системе, а в Oracle. Тот же механизм indirect-буферов прекрасно работает и на обычных /* 2GB */ ядрах, это тоже проверено.

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