Очень такая скромно требовательная к ресурсам СУБД.
Обратите внимание на эффективное распределение памяти. :)
Да, это не MySQL конечно, но MySQL'у зато есть куда расти.
Опен-сурс форева ;)
Итак, вниманию народа прилагается не скриншот, но 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 оперативки :-))
Факт, путают :-) На объем разделяемой памяти (shared memory) действительно есть ограничение 2/4GB, а вот на SGA оно гораздо более слабое, и вывести SGA за эти границы можно "легко и непринужденно" :-)
Дык что это такое?
trick от Оракле или еще что? ;)
Насчет RH ядро необязательно- при тестинге на 2.6.7 под реальной нагрузкой сервер потихоньку начинает "отставать"
скорость падает потихонку.
stamp сделан на машине с 512М- а сколько свапа?
Тут проблема не в том чтобы цифры были большие
а чтобы это реально работало и не тормозило.
> И насчет ядра- ты поставь ядро от RH задействуй ramfs и вот там SGA подними
В соответствии с редхатовскими whitepapers рекомендуется использовать mount -t shm. Кто этого не сделал - тот ССЗАД (Сам Себе Злобный Антропоморфный Дендромутант :-))
А насчет редхатовского ядра - в соответствии с документацией загрузил на RHEL'овском ядре на shmfs... Ты не поверишь но все работает, и цифры те же самые.
К чему я веду - а к тому, что если кто-то не умеет читать документацию, считает себя самым умным и огребает с этого проблемы с производительностью (а судя по показателям они у тебя есть), то это его собственные трудности, не находишь?
Ладно, если когда-нибудь пойдешь в оракловый и редхатовый саппорт (не приведя тебя боже), они тебя просветят о том, что разгребают только проблемы тех, кто правильно пользуется документацией :-)
P.S.: прочти notes'ы в исходниках rams и tmpfs (последняя лежит в mm/shmem.c) - тогда ты поймешь, почему не следует использовать ramfs :-)
ount -t shm ...
у да, где уж нам доки почитать,
там еще если что и chown oracle.dba /dev/shm надо ;)
> А насчет редхатовского ядра - в соответствии с документацией загрузил > на RHEL'овском ядре на shmfs... Ты не поверишь но все работает, и
> цифры те же самые.
А можно скрин? ;) именно 4 гига памяти и тп? и оракл 9.2.5.0
Я незнаю что там насчет SGA на системах с <2Gb, но дальше я так понял начинается самое интересное и глючное ;)
notes'ы не спорю не читал, завтра посмотрю че там про ramfs.
Сам Оракл, если я не ошибаюсь, не рекомендует использовать hugetlb ядро а юзать именно через ramfs.
Памяти на полигоне не 4GB (а трогать боевую машину чтобы удовлетворить твое любопытство я не стану) - но зато 4.8GB swap, ядро под 64GB. Опробовано, как я говорил, на 2.6 и RHEL'овском, которое с той же разверткой под память - характеристики одинаковые, однако 2.6 побыстрее оказывается. Если хочешь - могу сделать на рабочей станции скрин с того конфига, результаты которого показывал.
> Я незнаю что там насчет SGA на системах с <2Gb, но дальше
> я так понял начинается самое интересное и глючное ;)
Да ничего там не начинается - опции 64GB/4GB влияют на глобальную работу VM, и глюки лезут в любой конфигурации.
В доке с металинка chown говорят надо и все такое.
OracleonLinux.pdf если не ошибаюсь достаточно старый и касается только AS 2.1 а про 3 ничего там не сказано. Ты мож 2.1 ставил?
Ядро под 64Gb- если не ошибаюсь это hugeTLB ядро, сам Оракл его рекомендует использоваться когда на машине больше 4 гиг памяти и опять же на металинке написано было что могут возникнуть немаленькие проблемы с производительностью.
Мне просто интересно- ты пробуешь именно на AS3 upd 2 или чем-то другом?
> Ядро под 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 */ ядрах, это тоже проверено.