Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9   вперед  Ctrl      все
 Re: Informix displaces Oracle at China Telcom  [new]
herr
Member

Откуда:
Сообщений: 163
Yo.!
Выбегалло

DB2 ver 9.5 - пример приложения, в котором "перфоманс начинают выжимать уже из скоростей переключения контекста". Иначе с хрена ли бы им переходить на новую архитектуру ?

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

Yo.! дайте ссылку, вместе почитаем, когда-там у DB2 процессы были под Windows?
7 янв 09, 21:47    [6654185]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
herr
Member

Откуда:
Сообщений: 163
offtop:

например, зачем нужен thread-based, смотрите последний пост
https://www.sql.ru/forum/actualthread.aspx?tid=490648&hl=thread
7 янв 09, 21:56    [6654206]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Yo.!
Выбегалло

DB2 ver 9.5 - пример приложения, в котором "перфоманс начинают выжимать уже из скоростей переключения контекста". Иначе с хрена ли бы им переходить на новую архитектуру ?

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


О процессах в винде никто речи не ведет - там испокон веку все (O, DB2, Inf, Sybase, Ms) используют нити .
7 янв 09, 23:15    [6654341]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Справка 1.
onstat-
при этом уклонились от ответа на вопрос как поделить
конкретный буферный пул на несколько LRU.

Он делится автоматически исходя из числа процессоров в системе (cpu_count) и числа буферов кэша.
До 9i существовал параметр db_block_lru_latches которым можно было подкрутить автоматически установленное значение, с 9i он стал скрытым и не рекомендован к изменению.

onstat-

Увеличивайте количество LRU, тем самым уменьшите спины.

Честно говоря никогда не наблюдал конкуренции на защелках LRU списков, в Oracle (да думаю и у других) они используются только когда надо найти место для вновь считанного с диска блока, т.е. для орперации которую буферный кеш и стремится сократить. Конкуренция обычно возникает при поиске нужного блока в кеше (т.е. при логической операции чтения, коих случается значительно больше), а этот поиск Oracle выполняет отнюдь не по LRU спискам (опять же думаю как и у других СУБД, поскольку LRU списки приспособлены для поиска давно не используемого блока, а не для поиска требуемого блока), а по специальной отдельной HASH-структуре, в Oracle её называют 'cache buffer chains', которая имеет свои латчи. Рулить размером этой таблицы тоже можно и так же за это отвечает скрытый параметр, т.е. в большинстве случаев рулить не рекомендуется.

References:
Database Writer and Buffer Management. Nitin Vengurlekar. Oracle corp.

Справка 2, (про Oracle механизмы доступа к latch и spin_count )
В оракле есть два механизма получения доступа к защелкам (latch), один из них
уже упоминавшийся здесь 'Willing-to-Wait', т.е. выполнение _spin_count попыток и потом при неудаче сон и после тайм аута новая попытка. Второй метод 'Latch Wait Posting', когда процесс не получивший доступ к защелке перед тем как заснуть ставит себя в очередь на доступ к защелке,
а процесс освобождающий защелку проверяет список ожидающих (latch wait list) и если он не пуст будет следующего.
По умолчанию 'wait posting' применяется только для двух видов защелок ('library cache','shared pool'), связанных со структурами для хранения планов запросов, кода процедур и пакетов и т.п.
Режим 'wait posting' можно отключить для всех защелок или наоборот включить для всех опять же скрытым параметром. Но даже при включении 'wait posting' для всех защелок он не используется для защелок 'cache buffer chains', т.е. как раз защелок используемых при поиске в буферном кеше
о котором здесь и идет основное обсуждение.
Это можно трактовать двояко или доступ к буферам настолько быстр, что засыпание с последующим бужением оказывается дороже небольшого цикла попыток доступа или Oracle реализация 'wait posting' не очень удачна.

References:
Oracle 8i Internal Services for Waits, Latches, Locks and Memory. Steve Adams. O'Rally ISBN:1-56592-598-x
7 янв 09, 23:57    [6654402]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Выбегалло
Apex
Выбегалло

Зл0й
Теперь полезли искать эти преимущества в архитектуре сервера. Их там тоже нет. Потому, что как показывает практика многопоточная архитектура сервера СУБД не дает никаких ощутимых преимуществ по сравнению с многопроцессной.


А вот это в принципе неверно.
Переключение контекста в нити происходит на порядок быстрее, чем переключение контекста между процессами. Кроме того, нить "знает" когда можно отдать выполнение другой нити, а процесс переключается принудительно и может бестолку занимать CPU. Недаром IBM решила перейти на нитевую архитектуру в DB2

Да хоть на два порядка, сколько это в абсолютном значении? И сколько это в процентах от общего времени отклика? Покажите мне хоть одно, настолько хорошо написанное предложение, где перфоманс начинают выжимать уже из скоростей переключения контекста!


DB2 ver 9.5 - пример приложения, в котором "перфоманс начинают выжимать уже из скоростей переключения контекста". Иначе с хрена ли бы им переходить на новую архитектуру ?


На виндах переключение контекста происходит через задницу, поэтому производительность приложения состоящего их множества процессов ниже плинтуса. Поэтому на виндах Оракл тоже представляет собой один процесс с трэдами. Оракл мог бы и на Юниксах так сделать, но это не имеет смысла. Нормально написанные приложения на оракле крайне редко упираются в wait events связанные с межпроцессным взаимодействием. Как правило время ожидания на них сопоставимо со статистической погрешностью измерения.
8 янв 09, 00:05    [6654420]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
Оракл мог бы и на Юниксах так сделать, но это не имеет смысла

Имхо скорее "имеет смысл так не делать". С точки зрения, например, выживания приложения при падении одного из процессов..
8 янв 09, 11:54    [6655185]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
Выбегалло

О процессах в винде никто речи не ведет - там испокон веку все (O, DB2, Inf, Sybase, Ms) используют нити .


хм ... действительно

Я и ёжик
Второй метод 'Latch Wait Posting', когда процесс не получивший доступ к защелке перед тем как заснуть ставит себя в очередь на доступ к защелке, а процесс освобождающий защелку проверяет список ожидающих (latch wait list) и если он не пуст будет следующего.

ну вот нашелся аналог очереди и "responsibility of the thread releasing the resource to awake the first thread on the queue"
8 янв 09, 13:26    [6655510]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!

ну вот нашелся аналог очереди и "responsibility of the thread releasing the resource to awake the first thread on the queue"



Без информации о том, как операционака знает, что нужно переключать контекст именно на
first thread on the queue:

(C) Yo!
это рекламный слоган, типа шелковистых волос, никакой информации не несет :(
8 янв 09, 14:28    [6655702]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
onstat-
Без информации о том, как операционака знает, что нужно переключать контекст именно на
first thread on the queue

Операционка этого и не должна знать,очередь это внутренняя структура которую Oracle ведет для Latch. Тут идет совершенно стандартный механизм взаимодействия процессов в OS, процесс (1) записывает себя в очередь и засыпает на семофоре OS, процесс (2) заканчивает свою работу, видит, что есть очередь к ресурсу который он держал и сбрасывает соответствующий симофор OS (вероятно номер симофора это часть информации записываемой в очередь). Далее OS видит , что симофор на котором у нее спит процесс сброшен и ставит соответствующий процесс в очередь на выполнение.
8 янв 09, 15:40    [6656008]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
terrarium
Guest
to "Я и ёжик"

странно видеть тут вас двоих :)
А скажите реализация в windows какие имеет недостатки/достоинства окромя, что "все в одном процессе"?
10 янв 09, 00:45    [6661799]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
ёжик с финской границы
Guest
terrarium
to "Я и ёжик"

странно видеть тут вас двоих :)
А скажите реализация в windows какие имеет недостатки/достоинства окромя, что "все в одном процессе"?
я не сталкивался с промышленными инсталяциями oracle под windows, поэтому ничего сказать не могу.
10 янв 09, 11:02    [6662183]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
ёжик с финской границы
Guest
terrarium
to "Я и ёжик"

странно видеть тут вас двоих :)
А скажите реализация в windows какие имеет недостатки/достоинства окромя, что "все в одном процессе"?
я не сталкивался с промышленными инсталяциями oracle под windows, поэтому ничего сказать не могу.
10 янв 09, 16:44    [6663100]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
чя321
Guest
Контекст кончечно контекстом и скорость его переключения важна, особенно в граничных случаях.

Насколько мне известно, IBM DB2 перешла на threads потому как у операционной системы типа AIX, Solaris, HP-UX крышу сносит от 2000-3000 активных процессов и OS при такой нагрузке не знает как оптимально управлять специфичной нагрузкой на БД. Потому как schedulers операционной системы тоже имеют недостатки, и в таких пограничных ситуациях они начинают проявляться.
19 янв 09, 10:23    [6703284]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
чя321
Контекст кончечно контекстом и скорость его переключения важна, особенно в граничных случаях.

Насколько мне известно, IBM DB2 перешла на threads потому как у операционной системы типа AIX, Solaris, HP-UX крышу сносит от 2000-3000 активных процессов и OS при такой нагрузке не знает как оптимально управлять специфичной нагрузкой на БД. Потому как schedulers операционной системы тоже имеют недостатки, и в таких пограничных ситуациях они начинают проявляться.


А пацаны из оракла просто дописали к серверу приблуду под названием MTS (по новому shared server). Вместо того чтобы на каждую сессию создавать процесс (dedicated server process), создаются совместно используемые сессиями процессы. То есть архитектура собственно сервера осталась неизменной, поменяли только один кусок. Как показывает практика, эта фича используется крайне редко, потому что грамотные разработчики web-приложений обычно используют connection pool а доля приложений с тяжелым клиентом неуклонно падает каждый год.

Все эти дорогостоящие архитектурные оптимизации сервера под случаи которые происходят "раз в миллион лет" напоминают мне установку спойлера на автомобиль ВАЗ-2106. Чисто теоретически все логично - машина заднеприводная и создавать дополнительный момент прижимающий ведущие колеса к дороге полезно. На практике же, сколько-нибудь ощутимый эффект от использования спойлера появляется на скоростях от 180 до 200 километров в час. То есть на скоростях развить которые этот автомобиль конструктивно не способен.
19 янв 09, 20:41    [6707263]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Зл0й
чя321
Контекст кончечно контекстом и скорость его переключения важна, особенно в граничных случаях.

Насколько мне известно, IBM DB2 перешла на threads потому как у операционной системы типа AIX, Solaris, HP-UX крышу сносит от 2000-3000 активных процессов и OS при такой нагрузке не знает как оптимально управлять специфичной нагрузкой на БД. Потому как schedulers операционной системы тоже имеют недостатки, и в таких пограничных ситуациях они начинают проявляться.


А пацаны из оракла просто дописали к серверу приблуду под названием MTS (по новому shared server). Вместо того чтобы на каждую сессию создавать процесс (dedicated server process), создаются совместно используемые сессиями процессы. То есть архитектура собственно сервера осталась неизменной, поменяли только один кусок. Как показывает практика, эта фича используется крайне редко, потому что грамотные разработчики web-приложений обычно используют connection pool а доля приложений с тяжелым клиентом неуклонно падает каждый год.

Все эти дорогостоящие архитектурные оптимизации сервера под случаи которые происходят "раз в миллион лет" напоминают мне установку спойлера на автомобиль ВАЗ-2106. Чисто теоретически все логично - машина заднеприводная и создавать дополнительный момент прижимающий ведущие колеса к дороге полезно. На практике же, сколько-нибудь ощутимый эффект от использования спойлера появляется на скоростях от 180 до 200 километров в час. То есть на скоростях развить которые этот автомобиль конструктивно не способен.


Пацаны из Информикса написали такую приблуду под названием Connection Manager году, если мне не изменяет мой склероз, в 1999м. Несмотря на нитевую архитектуру.

Оптимизация сервера под нити - это отнюдь не "случай, который происходит раз в миллион лет". Выигрыш имеется изначально и растет с увеличением нагрузки.
19 янв 09, 20:54    [6707291]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7673
На самом деле дискуссия перешла в плоскость "Pre-emptive vs. Cooperative Multitasking". Преимущества и недостатки обоих давно известны. При "правильном" использовании ...

автор
- Cooperative Multitasking: Mostly avoids the need to explicitly
control resource sharing. Allows you to violate "invariants"
to boost performance as long as things are restored to normal
before the next task switching point.

- Pre-emptive Multitasking: Doesn't lose control to buggy
applications.
Что и сделал Informix. Азбучные истины, в общем-то...
19 янв 09, 21:01    [6707312]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Relic Hunter
На самом деле дискуссия перешла в плоскость "Pre-emptive vs. Cooperative Multitasking". Преимущества и недостатки обоих давно известны. При "правильном" использовании ...

автор
- Cooperative Multitasking: Mostly avoids the need to explicitly
control resource sharing. Allows you to violate "invariants"
to boost performance as long as things are restored to normal
before the next task switching point.

- Pre-emptive Multitasking: Doesn't lose control to buggy
applications.
Что и сделал Informix. Азбучные истины, в общем-то...


И это тоже. Имея весь код на руках, глупо заниматься pre-emptive miltitasking. И наоборот, имея код от третьих фирм, глупо на него уповать (вспоминая винду-95ю).
20 янв 09, 08:21    [6708087]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Выбегалло

Оптимизация сервера под нити - это отнюдь не "случай, который происходит раз в миллион лет". Выигрыш имеется изначально и растет с увеличением нагрузки.


Выигрыш если и имеется изначально, то в пределах погрешности измерения. Что-то между сотой и десятой частью процента и растет в лучшем случае где-то до четверти процента от времени затраченного на выполнение запроса. Это так, исходя из того сколько времени запрос в сумме тратит на все ожидания которых можно избежать с помощью нитевого сервера.
21 янв 09, 04:33    [6713295]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Зл0й
Выбегалло

Оптимизация сервера под нити - это отнюдь не "случай, который происходит раз в миллион лет". Выигрыш имеется изначально и растет с увеличением нагрузки.


Выигрыш если и имеется изначально, то в пределах погрешности измерения. Что-то между сотой и десятой частью процента и растет в лучшем случае где-то до четверти процента от времени затраченного на выполнение запроса. Это так, исходя из того сколько времени запрос в сумме тратит на все ожидания которых можно избежать с помощью нитевого сервера.


Рядом с таким сильным утверждением неплохо бы смотрелась ссылочка.
21 янв 09, 07:48    [6713363]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
чя321
Guest
2Злой:
Можно подумать СУБД состоит только и пользовательских процессов?
А как на счет системных процессов например DBWRITE/DBREAD или как они там в Oracle называются.
В системе с терабайтами данных их немало...
21 янв 09, 18:25    [6717936]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Informix Guest
Guest
2008 VendorRate Annual Report
22 янв 09, 11:17    [6719975]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5031
How multithreaded architecture works in DB2 9.5.
Упор делается на:
---
Here are some of the advantages of the new memory model:

* The new memory model is simpler and more easily configured.
* This model saves resources:
Significantly fewer system file descriptors are used. The most obvious distinction between processes and threads is that all threads of a process share the same memory space and system-defined facilities. Facilities include open file handles (file descriptors), shared memory, process synchronization primitives, and current directory. All threads in a process can share the same file descriptors. There is no need to have each agent maintain its own file descriptor table.
* Performance is enhanced:
Operating systems can generally switch (context switching) faster between threads of the same process than between different process. There is no need to switch address space. Because global memory is shared and almost no new memory must be allocated, creating a thread is simpler and faster than creating a process. Process creation is expensive in terms of processor cycles and memory usage.
* There are more automatic and dynamic configurable parameters, so less is required from the DBA.
---
22 янв 09, 11:48    [6720194]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Выбегалло
Зл0й
Выбегалло

Оптимизация сервера под нити - это отнюдь не "случай, который происходит раз в миллион лет". Выигрыш имеется изначально и растет с увеличением нагрузки.


Выигрыш если и имеется изначально, то в пределах погрешности измерения. Что-то между сотой и десятой частью процента и растет в лучшем случае где-то до четверти процента от времени затраченного на выполнение запроса. Это так, исходя из того сколько времени запрос в сумме тратит на все ожидания которых можно избежать с помощью нитевого сервера.


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


Ссылочка на что? Достать вам с production environment и выложить statspack/AWR report? Боюсь начальство не разрешит, т.к. в нем SQL. Может на слово поверите?
23 янв 09, 04:36    [6724423]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
чя321
2Злой:
Можно подумать СУБД состоит только и пользовательских процессов?
А как на счет системных процессов например DBWRITE/DBREAD или как они там в Oracle называются.
В системе с терабайтами данных их немало...


Оракл с включенным сбором AWR для каждого запроса хранит сколько времени было потрачено на:
- исполнение на проце
- ввод-вывод (несколько разных видов)
- ожидание на блокировках
- ожидание на "защелках" (latch wait) т.е. примитивах синхронизации самой СУБД.

Сия информация доступна через каталог (Data Dictionary), можно посчитать сколько процентов от времени выполнения запроса уходит на ожидание на "защелках". Так вот, даже если архитектура сервера представляет недостижимый идеал, при котором этого ожидания не происходит совсем, то существенной экономии достигнуть не удастся. От силы выжмете процент-два, если очень повезет. Все это при условии что приложение разработано грамотно и учитывает специфику СУБД Оракл и что DBA грамотно настроил СУБД. В противном случае ожидание на "защелках" может представлять собой проблему. Но лечится эта проблема не переписыванием сервера СУБД а грамотной разработкой приложения и настройкой СУБД.

Если глянуть в архитектуру Информикса, то его трэды это модель которая у жабокодеров называецца green threads. От нее в жабе кажись ушли еще в версии 1.2-1.3 лет этак много тому назад. От кооперативной многозадачности в ОС тоже в общем-то ушли очень давно. И правильно сделали. Допустим донаписал я свой собственный DataBlade к информиксу, и лажанулся в процессе (с кем не бывает). Энтот блэйд уложит мне весь информикс к ядрене фене. В Оракле если я лажанулся аналогичным образом то отвалится пользовательский процесс и этим дело скорее всего законится. Я уж не говорю что архитектура из одного тяжелого процесса у которого все "внутрях" конфликтует с изначальной идеологией Юникса который по идее писался как time sharing system, которая по идее не должна давать одному процессу монополизировать всю железяку. Оно конечно Юникс - система гибкая, можно извратиться и заставить ее работать совсем не так как она должна работать. Только может лучше грамотную архитектуру сервера делать с самого начала, чтобы не пришлось извращаться и издеваться над ОС - основной платформой на которой абсолютное большинство production systems крутятся?
23 янв 09, 05:04    [6724429]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
чя321
2Злой:
В системе с терабайтами данных их немало...


Хотите я про терабайты, телеком и СУБД вам правду-матку рубану, с плеча? Для типичных телекомовских задачек (сотни терабайт данных + нетривиальная аналитика), при желании можно вообще без СУБД обойтись. То есть и Оракл и Информикс и DB2 c Teradata - неэффективное решение данной задачи. Лет этак 10 тому назад просто не было другого выбора. "Мыши плакали и кололись, но ели кактус" (С). Сейчас выбор есть. Самую тяжелую часть работы связанную с обработкой терабайт данных выполняет не СУБД, а совсем другая хреновина. А реляционная СУБД сегодня предстваляет собой витрину/ларек данных (Data Mart). Если тупо и злобно по книжке строить реляционное хранилище, то при "взрослых" телекомовских объемах эта затея обойдется примерно в рыночную капитализацию всей телекомовской компании.
23 янв 09, 05:18    [6724434]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить