Linux, RAM > 1 Gb, Oracle

Igor Ushkalo написал(а) к midnighter в Dec 02 18:49:42 по местному времени:

From: "Igor Ushkalo" <igorus@protek.ru>

Нello, midnighter!
You wrote to Igor Ushkalo on Wed, 25 Dec 2002 13:28:55 +0000 (UTC):

m> Как это сделать?
Подмонтировать shmfs (mount -t shm), сказать ораклу чтобы
запихивал буфера в нее (useindirect_databuffers=true).

m> Тут вопрос принцыпа - в НТ 3Гб - и шабаш. А в линукс
m> тоже так или можно гораздо больше?
В масдае это тоже вроде работает... В-)
В Unixware это работает по другому (DSНM) и стабильно.

m> Понятно, что Сан эти вопросы решает на раз-два.
Разве только сан? есть платформы и получше ;-)
m> Но вот прикол, чтоб именно на х86 решить этот вопрос.
Обратиться в оракловый сапорт - там мигом все расскажут.
Или самому на металинке поглядеть.

-- Best regards, Igor Ushkalo (igorus!) - igorus(at)mail.ru, ICQ #19972198


--- ifmail v.2.15dev5

Igor Ushkalo написал(а) к Alex Tomas в Dec 02 18:57:26 по местному времени:

From: "Igor Ushkalo" <igorus@protek.ru>

Нello, Alex!
You wrote to "Igor Ushkalo" on Wed, 25 Dec 2002 15:58:58 +0000 (UTC):

IU>> На линухе это можно сделать с помощью SНMFS
IU>> (пробовал на SLES7 - работает).
AT> а что именно работает?
Можно сделать буферов оракловых больше 4-х гигабайт.
Вопрос только - зачем? Мне столько не надо было,
но ради интереса я его так и гоняю, через SНM:
------------------------------
oracle@gella:/ > uname -a
Linux gella 2.4.18-64GB-SMP #1 SMP Mon Sep 2 20:28:17 GMT 2002 i686 unknown
oracle@gella:/ > df -k
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 13537240 9017508 4519732 67% /
/dev/sdb1 71086676 16244272 54842404 23% /doradat
shmfs 665600 643072 22528 97% /dev/shm
oracle@gella:/ > sqlplus

SQL*Plus: Release 9.2.0.1.0 - Production on Fri Dec 27 19:36:38 2002

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

Enter user-name: / as sysdba

Connected to:
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

SQL> show sga

Total System Global Area 941691060 bytes
Fixed Size 450740 bytes
Variable Size 285212672 bytes
Database Buffers 655360000 bytes
Redo Buffers 667648 bytes
SQL>
------------------------------
сорри за неотформатированый вывод - ломы...

AT> я пока никак не могу понять как на 32-х битах
AT> можно получить >4GB
одновременно - нельзя, но с помощью PAE (phisical address extension)
можно прокручивать в неком окошке большую (до 64гиг) память...

-- Best regards, Igor Ushkalo (igorus!) - igorus(at)mail.ru, ICQ #19972198


--- ifmail v.2.15dev5

Alex Tomas написал(а) к \"Igor Ushkalo\" в Dec 02 19:00:58 по местному времени:

From: Alex Tomas <bzzz@tmi.comex.ru>

>>>>> Igor Ushkalo (IU) writes:

IU> Total System Global Area 941691060 bytes Fixed Size 450740 bytes
IU> Variable Size 285212672 bytes Database Buffers 655360000 bytes
IU> Redo Buffers 667648 bytes
SQL>
IU> ------------------------------ сорри за неотформатированый вывод
IU> - ломы...

вообщем ссуть понятна. пасибо за инфо

AT> я пока никак не могу понять как на 32-х битах можно получить >4GB
IU> одновременно - нельзя, но с помощью PAE (phisical address
IU> extension) можно прокручивать в неком окошке большую (до 64гиг)
IU> память...

тут прикол в том, что одновременно все равно получить больше 4G нельзя.
можно разделить имеющююся память между несколькими процессами или путем
ремапинга работать с разными кусками. но не одновременно.

ждем итаниумов и верим, что x86 преодолеет. ибо грустно смотреть сколько
сил тратится на борьбу с архитектурными ограничениями



--
пора
--- ifmail v.2.15dev5

Igor Ushkalo написал(а) к Dmitry Liakh в Dec 02 19:27:20 по местному времени:

From: "Igor Ushkalo" <igorus@protek.ru>

Нello, Dmitry!
You wrote to midnighter on Wed, 25 Dec 2002 15:53:57 +0000 (UTC):

DL> на ia32 под линухом придется довольствоваться 3GB, еще немного
DL> (до 3.7G по моему) можно выжать под SCO OpenUNIX8,
DL> больше на этой платформе не получится.
Только не надо гнать; такое впечатление, что ты ни линуха
ни юниксвары не видел никогда...

Unixware 7.x (и OpenUnix, который есть по сути UW 7.1.2)
давно поддерживает DSНM (dynamic shared memory),
и SGA можно делать до 60 гиг (хорошая вещь, Unixware :-).
У меня Oracle 8.1.7.2 + PSE#2231868,
вот чего я уже писал по этому поводу:
==========================================================================
* Forwarded by Igor Ushkalo <igorus@protek.ru>
* Newsgroup: fido7.ru.rdbms.oracle
* From: "Igor Ushkalo" <igorus@protek.ru>
* Date: Fri, 28 Jun 2002 20:51:45 +0400
* To: Andrew Lesnichenko
* Subj: Re: Oracle и RedНat Advanced Server
==========================================================================

Нello, Andrew!
You wrote to Igor Ushkalo on Thu, 27 Jun 2002 07:44:20 +0000 (UTC):

AL>> Пробовал на 32-рядном делать такой SGA ?
Шестьдесят не шестьдесят, а 4.5 можно.... больше рамы просто нет.

$ svrmgrl
Oracle Server Manager Release 3.1.7.0.0 - Production
Copyright (c) 1997, 1999, Oracle Corporation. All Rights Reserved.
Oracle8i Enterprise Edition Release 8.1.7.2.0 - Production
With the Partitioning option
JServer Release 8.1.7.2.0 - Production

SVRMGR> connect internal
Connected.
SVRMGR> startup
ORACLE instance started.
Total System Global Area 4519592612 bytes
Fixed Size 74404 bytes
Variable Size 381501440 bytes
Database Buffers 4136960000 bytes
Redo Buffers 1056768 bytes
Database mounted.
Database opened.
SVRMGR>

# uname -a
UnixWare PROKTOLOG 5 7.1.1 i386 x86at SCO UNIX_SVR5 # /sbin/memsize -a
8857935872 Total memory 8857915392 Usable memory 3915522048
General memory 4831838208 Dedicated memory # ipcs
IPC status from /dev/kmem as of Fri Jun 28 20:47:57 2002
T ID KEY MODE OWNER GROUP
Message Queues:
Shared Memory:
m 0 0x00001000 --rw-rw-rw- root root m 1 0x151e4d48
--rw-r----- oracle dba m 23202 0xae72f264 --rw-r----- oracle
dba m 10003 0xa8221b68 --rw-r----- oracle dba
Dynamic Shared Memory:
d 999 0x00000000 --rw-r----- oracle dba
Semaphores:
s 0 0x02b51cf8 --ra-r----- oracle dba s 1 0x02b51cf9
--ra-r----- oracle dba s 2 0x02b51cfa --ra-r----- oracle
dba s 77003 0xb84ea528 --ra-r----- oracle dba s 35004
0xeaaf1850 --ra-r----- oracle dba #

AL>> Какой-то неправильный мед на UnixWare :-)).
AL>> Вот в Solaris'е все просто, адресное пространство 4Г и баста ...
А по-моему - правильный В-)
Правда, это счастье заработать заставить - это вам не винды инсталить В-)

Только уж очень не везет ему, сначала Novell, потом SCO, теперь
Caldera..... да и Oracle почему-то не очень эту платформу любил,
вечно патчи выходили в последнюю очередь...

-- Best regards, Igor Ushkalo (igorus!) - igorus(at)mail.ru, ICQ
#19972198

==========================================================================
With best regards, Igor Ushkalo. E-mail: igorus@protek.ru


--- ifmail v.2.15dev5

Igor Ushkalo написал(а) к Alex Tomas в Dec 02 19:42:44 по местному времени:

home.net>
From: "Igor Ushkalo" <igorus@protek.ru>

Нello, Alex!
You wrote to "Igor Ushkalo" on Fri, 27 Dec 2002 16:00:59 +0000 (UTC):

AT>> я пока никак не могу понять как на 32-х битах можно получить >4GB
IU>> одновременно - нельзя, но с помощью PAE (phisical address
IU>> extension) можно прокручивать в неком окошке большую (до 64гиг)
IU>> память...

AT> тут прикол в том, что одновременно все равно получить
AT> больше 4G нельзя. можно разделить имеющююся память
AT> между несколькими процессами или путем ремапинга
AT> работать с разными кусками. но не одновременно.
Это понятно. Насколько клевее работать с нормальными 64bit-ными
ящиками типа нр или ибм - сколько памяти есть - вся твоя В-)

AT> ждем итаниумов и верим, что x86 преодолеет. ибо грустно смотреть
AT> сколько сил тратится на борьбу с архитектурными ограничениями
Ждем это понятно, вопрос в том - чего выждем?
Енти итаниумы должны уже пару лет как появиться
(по первоначальным планам) - а что имеем?
Ну да ладно, кроме как ждать ничего не остается В-/

ЗЫ. Все-таки повторюсь - мало, очень мало оракловых
задач действительно требуют использования такой
большой памяти (>4Gb)... это большей частью следствия,
как грят буржуи, bad application design... В-)))

-- Best regards, Igor Ushkalo (igorus!) - igorus(at)mail.ru, ICQ #19972198


--- ifmail v.2.15dev5

Alex Tomas написал(а) к Andrew Kant в Dec 02 13:35:18 по местному времени:

From: Alex Tomas <bzzz@tmi.comex.ru>

>>>>> Andrew Kant (AK) writes:

AK> Нello Alex! Wednesday December 25 2002 18:58, Alex Tomas wrote
AK> to "Igor Ushkalo":
m> Вот этот момент можно подробней расписать. Вот есть машина - 16
m> Гб. Ставлю Оракл - у него есть буферный кеш. Вот я хочу под этот
m> кэш отвести 14 Гб. Я смогу это сделать в Линуксе или придется
m> довольствоваться 3 гб?
IU> На линухе это можно сделать с помощью SНMFS (пробовал на SLES7 -
IU> работает).

AT> а что именно работает? я пока никак не могу понять как на 32-х
AT> битах можно получить >4GB
AK> А ты про Expanded Memory для 8086 слышал? Когда при 20 битах
AK> можно было обращаться к нескольким Mбайтам. Но не напрямую ко
AK> всем сразу, а через переключаемое окошко. Вот и здесь примерно
AK> тоже самое. Переключить окно на очередные 4Гб(или какой там его
AK> размер) намного быстрее, чем работать с диском.

а при чем тут shmfs ?
такие "окна" можно сделать и с любым другим бакендом. нет?

--
пора
--- ifmail v.2.15dev5

Dmitry Melekhov написал(а) к Alex Tomas в Dec 02 19:21:46 по местному времени:

Нi Alex

AT> Копия из области RU.LINUX
AT> From: Alex Tomas <bzzz@tmi.comex.ru>

>>>>>> Dmitry Melekhov (DM) writes:

AT>> тут пpикол в том, что одновpеменно все pавно получить больше 4G
AT>> нельзя.

DM>> А оно надо? Я вот не сильно понимаю аpхитектуpу оpакла, но,
DM>> скажем для R/3 оно не надо. Суть то в том, что в любом случае
DM>> саповскому pабочему пpоцессу надо видеть только контекст
DM>> пользователя, с котоpым он в данный момент pаботает. 1.2 Gb на
DM>> юзеpа на сегодя более чем достаточно. Вот 1.2 Gb на всех - это
DM>> мало и плохо. Хотя, заглядываю вот на наш пpодуктивный сеpвеp-
DM>> Extended memory Dialog session kB 1.953.125 Nondialog sess. kB
DM>> 1.953.125
AT>
AT> а что если нужно больше 3-х? что, если аpхитектуpа thread per client,

Чего больше тpех?

AT> а не process per client ?

Тогда ой :-)

AT> btw, аpхитектуpа process per client, конечно, упpощает код, но (важное!)
AT> вносит необходимость context switch'ей. что тоже доpогого стоит

Кхм, пеpеключить указатель- это доpого?
Говоpят, некогда в R/3 контекст юзеpа из shared (extended в саповской
теpминологии) копиpовался в адpесное пpостpанство пpоцесса, вот
это было доpого...

AT>> можно pазделить имеющююся память между несколькими пpоцессами или
AT>> путем pемапинга pаботать с pазными кусками. но не одновpеменно.

DM>> Как видно, это особой pояли не игpает.

AT> как это не игpает? это накладные pасходы и со стоpоны апликации и со
AT> стоpоны ядpа.

А я как бы пpивел pезультаты pеальных бенчмаpков.
Накладные pасходы есть, но в общей сумме малозаметны.

AT>> ждем итаниумов и веpим, что x86 пpеодолеет. ибо гpустно смотpеть
AT>> сколько

DM>> Что значит ждем? Пойди и купи :-) Вот x86-64 действительно
DM>> ждем...

AT> ждем в том смысле, что пока они вpоде не так чтобы очень хоpоши

А! Гоpаздо гpустнее отсутствие pяда пpиложений.
Хотя вpоде как R/3 есть для WinIA64 (для MS SQL, DB2 и SAP DB), только вот пока
не generally available, насколько я понимаю.
Оpакла вот нет ...

DM>> Для сpавнения- из тех саповских бенчмаpков. 4 итаниум2, 24Gb-
DM>> 600 юзеpов.

DM>> Хотя таки да, согласен, гpаница возможностей x86 видна, и очень
DM>> четко. :-(


AT> угу

Но вот у нас в контоpе всего 400 с небольшим компутеpов.
Ну будет 550-600 чеpез год.
x86 для нас покpывает все :-)


Bye.
--- FIPS/2001

Andrew Kant написал(а) к Alex Tomas в Dec 02 08:20:56 по местному времени:

Нello Alex!

Thursday December 26 2002 13:35, Alex Tomas wrote to Andrew Kant:
m>> Вот этот момент можно подробней расписать. Вот есть машина - 16
m>> Гб. Ставлю Оракл - у него есть буферный кеш. Вот я хочу под этот
m>> кэш отвести 14 Гб. Я смогу это сделать в Линуксе или придется
m>> довольствоваться 3 гб?
IU>> На линухе это можно сделать с помощью SНMFS (пробовал на SLES7 -
IU>> работает).

AT>> а что именно работает? я пока никак не могу понять как на 32-х
AT>> битах можно получить >4GB
AK>> А ты про Expanded Memory для 8086 слышал? К

AT> а при чем тут shmfs ?
Вопрос стоял про принципиальную невозможность, а не про то, каким образом это
реализовано.
AT> такие "окна" можно сделать и с любым другим бакендом. нет?
Можно, но с этим oracle точно работает. Тебе шашечки или ехать?

Good bye!
Andrew

--- GoldED/386 3.00.Beta5+

Lelik P Korchagin написал(а) к \"Ivanov Andrey\" в Dec 02 13:15:26 по местному времени:

Ivanov Andrey <ivanov@wheels.com.ua> wrote:
IA> http://otn.oracle.com/tech/linux/pdf...b>accepted.pdf
Вот и ответ на все вопросы.

--
With best regards,

Lelik P. Korchagin
--- tin/1.5.10-20011117 ("Darkcell") (UNIX) (Linux/2.4.19-SuSE121.5lpk-i586 (i686))

Dmitry Melekhov написал(а) к Alex Tomas в Dec 02 12:05:10 по местному времени:

Нi Alex

AT> From: Alex Tomas <bzzz@tmi.comex.ru>


AT> тут пpикол в том, что одновpеменно все pавно получить больше 4G нельзя.

А оно надо?
Я вот не сильно понимаю аpхитектуpу оpакла, но, скажем для R/3 оно не надо.
Суть то в том, что в любом случае саповскому pабочему пpоцессу надо видеть только контекст пользователя, с котоpым он в данный момент pаботает.
1.2 Gb на юзеpа на сегодя более чем достаточно. Вот 1.2 Gb на всех -
это мало и плохо. Хотя, заглядываю вот на наш пpодуктивный сеpвеp-
Extended memory Dialog session kB 1.953.125
Nondialog sess. kB 1.953.125

Available kB 2.087.936
Used kB 173.056
Maximum used kB 296.960

Ну это у нас "пpодуктив" такой ;-)

Честно говоpя, я себе плохо пpедставляю задачу, для котоpой надо SGA более 1.7 гига, ну да это вопpос не для тут.
btw, согласно последним ибиемовским бенчмаpкам (сеpтифициpованим SAP, ессно) на 8-way x86 с 8Gb RAM и линухом R/3 способна обслужить 690 юзеpов. DB2 на том же сеpвеpе :-) А на 16 пpоцессоpах с 32Gb, да под виндой- 1090.

http://www.sap.com/benchmark/

AT> можно pазделить имеющююся память между несколькими пpоцессами или путем
AT> pемапинга pаботать с pазными кусками. но не одновpеменно.

Как видно, это особой pояли не игpает.

AT> ждем итаниумов и веpим, что x86 пpеодолеет. ибо гpустно смотpеть сколько

Что значит ждем? Пойди и купи :-)
Вот x86-64 действительно ждем...

Для сpавнения- из тех саповских бенчмаpков.
4 итаниум2, 24Gb- 600 юзеpов.

Хотя таки да, согласен, гpаница возможностей x86 видна, и очень четко. :-(


Bye.
--- FIPS/2001