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

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Зл0й
С версионностью разобрались, закономерным образом не нашли у СУБД-блокировщиков (на примере Информикса) никаких существенных преимуществ.


Если бы одна из архитектур обладала существенными преимуществами, то вторая бы не выжила.


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


А вот это в принципе неверно.
Переключение контекста в нити происходит на порядок быстрее, чем переключение контекста между процессами. Кроме того, нить "знает" когда можно отдать выполнение другой нити, а процесс переключается принудительно и может бестолку занимать CPU. Недаром IBM решила перейти на нитевую архитектуру в DB2
5 янв 09, 20:10    [6649272]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
Выбегалло

Нет там никакого scheduler-а в понимании ОС. Потому что невытесняемая многозадачность. Каждая нить сама ставит себя в очередь к латчу и передает управление планировщику, который пробегает очередя, проверяет какие нити перешли в состояние готовности и переставляет их в очередь на выполнение, и запускает первую нить из очереди.

а есть нормальный документ описывающий, что там есть и чего нет ? а то onstat- нам рассказывал ровно противоположное.

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

как мы выяснили в информиксе нет нитей, есть их эмуляция в рамках процесса, не факт что эта эмуляция быстрей апаратного переключения целого процесса ОСи. а дб2 могла перейти на процессы например из бедности - не возможность поддерживать две ветки db2 luw (нитевую для виндовс и поцессорную для Unix/Linux).
5 янв 09, 20:58    [6649390]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

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


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


А вот это в принципе неверно.
Переключение контекста в нити происходит на порядок быстрее, чем переключение контекста между процессами.

На порядок только в MS Windows. В Линуксе на x86 и x86-64 примерно в полтора-два раза. Зависит от реализации ОС.

Выбегалло

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

Зато ОС (например Юникс) о том что происходит у процесса внутрях не ведает ни сном ни духом, и выделяет ему ресурсов исходя из неких заложенных в нее создателями предположений. Так что один здоровенный тяжеленный процесс с кучей тредов внутри не обязательно работает лучше. Чисто умозрительно можно придумать сценарий при котором произойдет некий "затык" по производительности из-за процессов а не трэдов. Можно придумать и сценарий при котором произойдет "затык" по производительности из-за того что ОС не даст ресурсов большому-толстому процессу. Как показывает практика, если руки не кривые то такой "затык" в природе не встречается, потому что в СУБД есть миллион других мест где таковой "затык" происходит по совершенно другим не зависящим от архитектуры сервера причинам.

Выбегалло

Недаром IBM решила перейти на нитевую архитектуру в DB2

Мы посмотрим что из этого выйдет, когда они на нее перейдут. Помнится лет этак пятнадцать тому назад один из лидеров рынка СУБД на тот момент решил перейти на блокировку уровня строки вместо блока (за 7м Ораклом погнались). Кончилось прискорбно, с большим скандалом.

Оно конечно можно слабать информикс который будет выдавать себя за DB2. Обе СУБД были в свое время написаны практически по одной спецификации, потму что ее писал один и тот же человек. Но это к "переходу на нитевую архитектуру" не имеет отношения. Просто у IBM оказалось 2 софтины написанных по одной спецификации. Выбрали ту которая поблатнее, а другую решили убить. А под какой маркой продавать будут - это к маркетроидам. Пусть хоть IMS обзовут, техники дела это не поменяет.
6 янв 09, 01:44    [6649880]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
info-win-3-1
Guest
То, что "придумал" информикс - называется "Cooperative Mutitasking". Штука известная по временам Windows 3.1, появившаяся, кстате, на два года раньше Informix 6 с переписанным ядром под использование нитей. Тогда это было модно. Я сам помню по институту )))

Cooperative multitasking/time-sharing
When computer usage evolved from batch mode to interactive mode, multiprogramming was no longer a suitable approach. Each user wanted to see his program running as if it was the only program in the computer. The use of time sharing made this possible, with the qualification that the computer would not seem as fast to any one user as it really would be if it were running only that user's program.

Early multitasking systems consisted of suites of related applications that voluntarily ceded time to each other. This approach, which was eventually supported by many computer operating systems, is today known as cooperative multitasking. Although it is rarely used in larger systems, Microsoft Windows prior to Windows 95 and Windows NT, and Mac OS prior to Mac OS X both used cooperative multitasking to enable the running of multiple applications simultaneously. Windows 9x also used cooperative multitasking, but only for 16-bit legacy applications, much the same way as pre-Leopard PowerPC versions of Mac OS X used it for Classic applications. Cooperative multitasking is still used today on RISC OS systems.

Because a cooperatively multitasked system relies on each process to regularly give time to other processes on the system, one poorly designed program can cause the whole system to hang.
6 янв 09, 01:58    [6649889]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

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

Нет там никакого scheduler-а в понимании ОС. Потому что невытесняемая многозадачность. Каждая нить сама ставит себя в очередь к латчу и передает управление планировщику, который пробегает очередя, проверяет какие нити перешли в состояние готовности и переставляет их в очередь на выполнение, и запускает первую нить из очереди.

а есть нормальный документ описывающий, что там есть и чего нет ?


http://docs.rinet.ru/InforSmes/ch07/ch07.htm#Heading7
автор


The VP holds the same responsibilities that the UNIX operating system has, managing time slices and the priority levels of the jobs allowed to run on the CPU. The VP manages the priority and scheduling of the threads connected to it. VPs are also responsible for switching threads when needed. Figure 7.6 shows a VP switching the context of two threads.

Figure 7.6.
Context switching performed on two threads by a virtual processor.

Threads are not restricted to work under a specific time slice as CPU processes are. A thread continues processing in the VP until it completes its task or until it must wait for something else to occur before it can continue. These waits are built into the thread's instructions, usually to take care of reads or writes or to free up locks. The VP sometimes learns from the running thread which thread should run next. This learning occurs when the thread realizes that it needs more information; it allows itself to be switched out so that another thread can be started to satisfy the need of the original thread.

Three types of queues hold the threads not running for each VP class. The ready queue is where all threads that are ready to run reside; that is, they have all the data needed to perform their task. The sleep queue is where threads that have no work to perform reside until there is work for them to do. The wait queue is where threads are placed when they need something else to complete before they can continue. Threads in sleep and wait queues are placed in the ready queue when they are needed to run again.

When there is more than one VP of the same class running, there is still only one set of queues. A thread waiting in the class queue is run on the first VP available. This provides a balance in the workload of each VP and provides faster work throughput of ready threads.

Multiprocessor systems also provide the capability to perform some tasks in parallel. Usually a client process has one session thread associated with it at one time. Tasks that require index building, sorting, sequential scanning, and joining can have more than one session thread. Figure 7.7 shows a client process with more than one session thread attached to various VPs. An example is when a client process reads through table data sequentially. If this table is fragmented over different disk partitions, a thread to read each partition's data can run at the same time. After all the partition reads are complete, the data is placed together by one thread and returned to the client. This process is also known as fan-out, where the single starting point of the fan is at the client. The fan becomes wider as multiple threads are created and connect to multiple VPs. Each of these VPs then connects to multiple CPUs.



Yo.!

а то onstat- нам рассказывал ровно противоположное.


Не надо придумывать.


Yo.!

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

как мы выяснили в информиксе нет нитей, есть их эмуляция в рамках процесса, не факт что эта эмуляция быстрей апаратного переключения целого процесса ОСи.

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


Yo.!

а дб2 могла перейти на процессы например из бедности - не возможность поддерживать две ветки db2 luw (нитевую для виндовс и поцессорную для Unix/Linux).


Это ваши фантазии, ссылки на документы давайте.
6 янв 09, 12:03    [6650222]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Зл0й


Мы посмотрим что из этого выйдет, когда они на нее перейдут. Помнится лет этак пятнадцать тому назад один из лидеров рынка СУБД на тот момент решил перейти на блокировку уровня строки вместо блока (за 7м Ораклом погнались). Кончилось прискорбно, с большим скандалом.


в качестве изучения истории, кто это был ?
ссылки можно ?

Зл0й

Оно конечно можно слабать информикс который будет выдавать себя за DB2. Обе СУБД были в свое время написаны практически по одной спецификации, потму что ее писал один и тот же человек. Но это к "переходу на нитевую архитектуру" не имеет отношения. Просто у IBM оказалось 2 софтины написанных по одной спецификации. Выбрали ту которая поблатнее, а другую решили убить. А под какой маркой продавать будут - это к маркетроидам. Пусть хоть IMS обзовут, техники дела это не поменяет.


ИМХО если бы все было написано по одной спецификации, то IBM не составило бы труда
взять из Informix все лучшее и перенести в DB2 как изначально планировалось,
но этого не произошло.
Развитие было притормозилось( с 2000 до 2004) , но потом ( после 2005 года) продукт
(технология Informix DSA ) продолжала не просто жить,
а и интенсивно развиваться. Настоящий топик тому доказательство.
6 янв 09, 12:32    [6650316]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

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

а есть нормальный документ описывающий, что там есть и чего нет ?



вот еще одни документ который может пролить свет как все происходит ( при желании понять)

http://www.informix-zone.com/idswiki/doku.php/idsdev:misc:mutex
6 янв 09, 13:17    [6650452]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
onstat-
The VP sometimes learns from the running thread which thread should run next. This learning occurs when the thread realizes that it needs more information; it allows itself to be switched out so that another thread can be started to satisfy the need of the original thread.

ну это рекламный слоган, типа шелковистых волос, никакой информации не несет :(
onstat-

вот еще одни документ который может пролить свет как все происходит ( при желании понять)

http://www.informix-zone.com/idswiki/doku.php/idsdev:misc:mutex

это уже лучше, но скуповато, описания каких-либо оптимизаций не нашел. зато нашел:
onstat-

Также системный вызов по взведению мутексов и семафоров
в ОС тоже операция не дешевая требует преключения контекста( выполнения кода на уровень ядра).


One of the more common ways to use a semaphore is to put a process to sleep on the semaphore waiting for a particular event to wake it up. Informix uses semaphores in this way for a VP process that does not have any further work to do.

почему вы думаете что взвыедение семофоров ОС для оракла дороже чем та же операция в информикс ?

ну и дальше:
This spinning is a tight loop in the code that does nothing. Every so many loops it would try for the latch again. This is more CPU intensive, but requires less operating system overhead than swapping the process in and out as it goes to sleep on the semaphore.

ничего не напоминает ? ну и чем это лучше ораклового _spin_count ? к стате сразу вопрос - как завется аналог _spin_count в IDS ?
6 янв 09, 13:48    [6650572]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo.!
onstat-
The VP sometimes learns from the running thread which thread should run next. This learning occurs when the thread realizes that it needs more information; it allows itself to be switched out so that another thread can be started to satisfy the need of the original thread.

ну это рекламный слоган, типа шелковистых волос, никакой информации не несет :(


Какая вам еще нужна информация?
Поставьте Informix и поробуйте, почитайте матчасть и многие вопросы сами собой отпадут.

Yo.!

onstat-

вот еще одни документ который может пролить свет как все происходит ( при желании понять)

http://www.informix-zone.com/idswiki/doku.php/idsdev:misc:mutex

это уже лучше, но скуповато, описания каких-либо оптимизаций не нашел. зато нашел:
onstat-

Также системный вызов по взведению мутексов и семафоров
в ОС тоже операция не дешевая требует преключения контекста( выполнения кода на уровень ядра).


One of the more common ways to use a semaphore is to put a process to sleep on the semaphore waiting for a particular event to wake it up. Informix uses semaphores in this way for a VP process that does not have any further work to do.


почему вы думаете что взвыедение семофоров ОС для оракла дороже чем та же операция в информикс ?


Потому что количество CPU VP равно или меньше количеству физических процессоров или ядер
( так рекомендует performance guid).
при этом эти CPU VP обрабатывают десятки, сотни или тысячи пользовательских сессий.

В Oracle didicated процесс(нить) обслуживает только одну сессию, а их ( dedicated) также
десятки , сотни или тысячи, для соизмеримых систем.
Теперь прикиньте разницу в количестве системных вызовов для синхронизации доступа к разделяемым ресурсам в памяти.
Хотите доказать обратное, приведите ссылку как Oracle синхронизирует доступ к разделяемым ресурсам dedicated процессов без использования системных вызовов.


Yo.!


ну и дальше:
This spinning is a tight loop in the code that does nothing. Every so many loops it would try for the latch again. This is more CPU intensive, but requires less operating system overhead than swapping the process in and out as it goes to sleep on the semaphore.

ничего не напоминает ? ну и чем это лучше ораклового _spin_count ? к стате сразу вопрос - как завется аналог _spin_count в IDS ?


Такие ситуации бывают редко, но бывают.
Вы их на практике видели?

Вот ответ на ваш вопрос:
автор
The threads are awakened and given the resource in the order that they have requested it. It is the responsibility of the thread releasing the resource to awake the first thread on the queue, change the head of the queue, and put the thread on the ready queue. The spinning mechanisms described under latches is still used, but only to get one of the latches in the mutex. The threads are never put to sleep on a semaphore to wait since there are now appropriate VP queues for them to wait in.


Вы _spin_count, вы ведернули из контекста, при этом уклонились от ответа на вопрос как поделить
конкретный буферный пул на несколько LRU.
Увеличивайте количество LRU, тем самым уменьшите спины.
Если есть не нагруженные CPUVP - остановите их это тоже уменьшает спины.
6 янв 09, 14:50    [6650823]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
я хочу увидеть документ описывающий оптимизацию, чтоб убедится что она существует, а не вы как с scip_commited что-то напутали.
onstat-

Теперь прикиньте разницу в количестве системных вызовов для синхронизации доступа к разделяемым ресурсам в памяти.

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

автор
The threads are awakened and given the resource in the order that they have requested it. It is the responsibility of the thread releasing the resource to awake the first thread on the queue, change the head of the queue, and put the thread on the ready queue. The spinning mechanisms described under latches is still used, but only to get one of the latches in the mutex. The threads are never put to sleep on a semaphore to wait since there are now appropriate VP queues for them to wait in.

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

onstat-
Вы _spin_count, вы ведернули из контекста, при этом уклонились от ответа на вопрос как поделить
конкретный буферный пул на несколько LRU.

уже вроде отвечал, повторяю:
автор
Considering Multiple Buffer Pools

A single default buffer pool is generally adequate for most systems. However, users with detailed knowledge of an application's buffer pool might benefit from configuring multiple buffer pools.

With segments that have atypical access patterns, store blocks from those segments in two different buffer pools: the KEEP pool and the RECYCLE pool. A segment's access pattern may be atypical if it is constantly accessed (that is, hot) or infrequently accessed (for example, a large segment accessed by a batch job only once a day).

Multiple buffer pools let you address these differences. You can use a KEEP buffer pool to maintain frequently accessed segments in the buffer cache, and a RECYCLE buffer pool to prevent objects from consuming unnecessary space in the cache. When an object is associated with a cache, all blocks from that object are placed in that cache. Oracle maintains a DEFAULT buffer pool for objects that have not been assigned to a specific buffer pool. The default buffer pool is of size DB_CACHE_SIZE. Each buffer pool uses the same LRU replacement policy (for example, if the KEEP pool is not large enough to store all of the segments allocated to it, then the oldest blocks age out of the cache).

By allocating objects to appropriate buffer pools, you can:

* Reduce or eliminate I/Os
* Isolate or limit an object to a separate cache


http://download.oracle.com/docs/cd/B10500_01/server.920/a96533/memory.htm#30936
6 янв 09, 16:25    [6651152]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

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


Мы посмотрим что из этого выйдет, когда они на нее перейдут. Помнится лет этак пятнадцать тому назад один из лидеров рынка СУБД на тот момент решил перейти на блокировку уровня строки вместо блока (за 7м Ораклом погнались). Кончилось прискорбно, с большим скандалом.


в качестве изучения истории, кто это был ?
ссылки можно ?

Сайбэйс. Впопыхах была выпущена новая версия которая при определенном стечении обстоятельств невосстановимо теряла данные - это был очень злобный баг. С этого начался закат Сайбэйса. Версию за давностью лет не помню, спросите Сайбэйсных DBA кто работал с этим продуктом году этак в 93-95 они вам расскажут.


onstat-

Зл0й

Оно конечно можно слабать информикс который будет выдавать себя за DB2. Обе СУБД были в свое время написаны практически по одной спецификации, потму что ее писал один и тот же человек. Но это к "переходу на нитевую архитектуру" не имеет отношения. Просто у IBM оказалось 2 софтины написанных по одной спецификации. Выбрали ту которая поблатнее, а другую решили убить. А под какой маркой продавать будут - это к маркетроидам. Пусть хоть IMS обзовут, техники дела это не поменяет.


ИМХО если бы все было написано по одной спецификации, то IBM не составило бы труда
взять из Informix все лучшее и перенести в DB2 как изначально планировалось,
но этого не произошло.
Развитие было притормозилось( с 2000 до 2004) , но потом ( после 2005 года) продукт
(технология Informix DSA ) продолжала не просто жить,
а и интенсивно развиваться. Настоящий топик тому доказательство.


Просто один талантливый дядька который проходил производственную практику на IBM и писал там спецификацию для DB2 по окончании своей учебы пошел работать в Информикс, который тогда только создавался. С той поры довольно много воды утекло, Информикс купил стоунбрэйкеровскую Иллюстру пытался толкать объектно-реляционную лажу, купил красный кирпич и пытался лезть в хранилища данных. Оба продукта слегка разошлись, но сходство все равно порой просто поразительное. Информикс на порядок ближе к DB2 чем любые 2 других коммерческих СУБД от разных производителей (кроме старого сайбэйса и MS SQL server версии примерно 6).
6 янв 09, 20:28    [6651734]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Зл0й
Member

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

Суть вопроса не сколько в скорости переключения в сумме времени потраченной на все переключения.


В Оракле при грамотно написаном приложении эта сумма времени часто составляет менее 0.1% от времени выполнения запроса. Поэтому любая оптимизация в данной области неоправдана. "premature optimization is the root of all evil." (C) Дональд Кнут
6 янв 09, 20:33    [6651746]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
Зл0й

Просто один талантливый дядька который проходил производственную практику на IBM и писал там спецификацию для DB2 по окончании своей учебы пошел работать в Информикс

а о которой db2 идет речь ? майнфреймовская db2 что-ли ? вроде на момент старта информикса у ibm ни каких намеков на unix, os/2 и даже as/400 не было ...
6 янв 09, 22:54    [6652053]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

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

Нет там никакого scheduler-а в понимании ОС. Потому что невытесняемая многозадачность. Каждая нить сама ставит себя в очередь к латчу и передает управление планировщику, который пробегает очередя, проверяет какие нити перешли в состояние готовности и переставляет их в очередь на выполнение, и запускает первую нить из очереди.

а есть нормальный документ описывающий, что там есть и чего нет ? а то onstat- нам рассказывал ровно противоположное.


Не знаю про доступные "нормальные" документы, я учился по внутренним.

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

как мы выяснили в информиксе нет нитей, есть их эмуляция в рамках процесса, не факт что эта эмуляция быстрей апаратного переключения целого процесса ОСи. а дб2 могла перейти на процессы например из бедности - не возможность поддерживать две ветки db2 luw (нитевую для виндовс и поцессорную для Unix/Linux).


Кто конкретно выяснил что в информиксе нет нитей ?
И как вы, собственно, понимаете разницу между нитью и процессом в юниксах?

-----------
http://en.wikipedia.org/wiki/Thread_(computer_science)

Threads are distinguished from traditional multitasking operating system processes in that processes:

* are typically independent,
* carry considerable state information,
* have separate address spaces, and
* interact only through system-provided inter-process communication mechanisms.

Multiple threads, on the other hand, typically share the state information of a process, and share memory and other resources directly. Context switching between threads in the same process is typically faster than context switching between processes
...
User thread or fiber implementations are typically entirely in userspace. As a result, context switching between user threads or fibers within the same process is extremely efficient because it does not require any interaction with the kernel at all: a context switch can be performed by locally saving the CPU registers used by the currently executing user thread or fiber and then loading the registers required by the user thread or fiber to be executed


Информикс использует свою собственную библиотеку user threads, DB2 полагается на posix threads, но оба варианта переключают контест гораздо быстрее чем процесс.

Ну и вашу шутку про переход DB2 на нитевую архитектуру от бедности я оценил.
6 янв 09, 23:37    [6652153]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
Выбегалло

Кто конкретно выяснил что в информиксе нет нитей ?
И как вы, собственно, понимаете разницу между нитью и процессом в юниксах?

понимаю, я не понимаю какое отношение имеют к "Информикс использует свою собственную библиотеку user threads".
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.admin.doc/admin237.htm
то что там нарисовано на картинке, на уровне ОС такое переключение процесса/нити процессор делает хардварно, как я понимаю библиотека информикс должна эмулировать такое переключение софтварно, т.к. с точки зрения процессора один процесс.
6 янв 09, 23:54    [6652208]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

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

Выбегалло

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

Зато ОС (например Юникс) о том что происходит у процесса внутрях не ведает ни сном ни духом, и выделяет ему ресурсов исходя из неких заложенных в нее создателями предположений.


Каких-таких ресурсов юникс может недодать ? Приоритетов ? Ну пользуйтесь noage параметром, чтобы "перцем не стареть", и получать всегда один и тот же квант времени / приоритет.


Зл0й
Так что один здоровенный тяжеленный процесс с кучей тредов внутри не обязательно работает лучше. Чисто умозрительно можно придумать сценарий при котором произойдет некий "затык" по производительности из-за процессов а не трэдов. Можно придумать и сценарий при котором произойдет "затык" по производительности из-за того что ОС не даст ресурсов большому-толстому процессу.


Пример ?


Зл0й
Выбегалло

Недаром IBM решила перейти на нитевую архитектуру в DB2

Мы посмотрим что из этого выйдет, когда они на нее перейдут. Помнится лет этак пятнадцать тому назад один из лидеров рынка СУБД на тот момент решил перейти на блокировку уровня строки вместо блока (за 7м Ораклом погнались). Кончилось прискорбно, с большим скандалом.


Дык перешли уже, 9.5. C October 31, 2007 - особых скандалов что-то не слышно.

Зл0й
Оно конечно можно слабать информикс который будет выдавать себя за DB2. Обе СУБД были в свое время написаны практически по одной спецификации, потму что ее писал один и тот же человек. Но это к "переходу на нитевую архитектуру" не имеет отношения. Просто у IBM оказалось 2 софтины написанных по одной спецификации. Выбрали ту которая поблатнее, а другую решили убить. А под какой маркой продавать будут - это к маркетроидам. Пусть хоть IMS обзовут, техники дела это не поменяет.


О как ! Значит, Informix начнут продавать под маркой DB2...
Признайтесь честно - вы ведь ни DB2, ни Informix толком не знаете?
7 янв 09, 00:00    [6652234]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Yo.!
я хочу увидеть документ описывающий оптимизацию, чтоб убедится что она существует, а не вы как с scip_commited что-то напутали.
onstat-

Теперь прикиньте разницу в количестве системных вызовов для синхронизации доступа к разделяемым ресурсам в памяти.

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


И какая же OS из используемых Ораклом позволяет хардверно переключать контекст ?


Yo.!
автор
The threads are awakened and given the resource in the order that they have requested it. It is the responsibility of the thread releasing the resource to awake the first thread on the queue, change the head of the queue, and put the thread on the ready queue. The spinning mechanisms described under latches is still used, but only to get one of the latches in the mutex. The threads are never put to sleep on a semaphore to wait since there are now appropriate VP queues for them to wait in.

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


Никто. Но все бесконечные лупы уже выловлены за долгие годы эксплуатации.
7 янв 09, 00:23    [6652284]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
Выбегалло

И какая же OS из используемых Ораклом позволяет хардверно переключать контекст ?

не знаю, до сегоднешнего дня все, но гугл нашел такую фазу:
Old versions of Linux took advantage of the hardware support offered by the 80x86 architecture and performed a process switch through a far jmp instruction[*] to the selector of the Task State Segment Descriptor of the next process. While executing the instruction, the CPU performs a hardware context switch by automatically saving the old hardware context and loading a new one. But Linux 2.6 uses software to perform a process switch ...


Выбегалло

Никто. Но все бесконечные лупы уже выловлены за долгие годы эксплуатации.

хм ... а что у информикса нет аналога SPL из db2 ? сторед процедуры компилирую отдельно, кто их исполнение контролирует ?
7 янв 09, 01:31    [6652499]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
фразу "не знаю, до сегоднешнего дня все, но гугл нашел такую фазу:" читать как "не знаю, до сегоднешнего дня думал, что все, но гугл нашел такую фазу:"
7 янв 09, 01:32    [6652502]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Yo.!
фразу "не знаю, до сегоднешнего дня все, но гугл нашел такую фазу:" читать как "не знаю, до сегоднешнего дня думал, что все, но гугл нашел такую фазу:"


Context switching can be performed primarily by software or hardware. Some processors, like the Intel 80286 and higher CPUs, have hardware support for context switches, by making use of a special data segment designated the Task State Segment or TSS. When a task switch occurs (implicitly due to a CALL instruction, referring to a task gate, or explicitly due to an interrupt or exception) the CPU can automatically load the new state from the TSS. With other tasks performed in hardware, one would expect this to be rather fast; however, mainstream operating systems, including Windows, do not use this feature.
7 янв 09, 07:36    [6652832]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

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


Выбегалло

Никто. Но все бесконечные лупы уже выловлены за долгие годы эксплуатации.

хм ... а что у информикса нет аналога SPL из db2 ? сторед процедуры компилирую отдельно, кто их исполнение контролирует ?


SPL - есть, конечно. Как конкретно происходит отдача управления я не знаю, но скорей всего код процедуры парсится, нить, отвечающая за выполнение процедуры, берет псевдокод и интерпретирует его покомандно, время от времени (скажем, после каждой десятой команды) отдавая процессор следующей нити из очереди готовых на выполнение. Таким образом, бесконечный цикл внутри процедуры не вызовет бесконечного захвата процессора.
Более интересна ситуация, когда процедура написана на C. В свое время на интервью меня спросили "в чем преимущества и недостатки информиксовской реализации хранимых процедур на С ?". Я тогда в informixе был практически ни в зуб ногой, как сейчас понимаю :-) , но интервьюир ответил сам : преимуществом и недостатком является выполнение таких процедур в адресном пространстве сервера. С одной стороны, получается быстро, без системных вызовов, семафоров и тд, но с другой стороны можно уронить сервер, или устроить, действительно, бесконечный цикл.
7 янв 09, 07:49    [6652835]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Выбегалло

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


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

Да хоть на два порядка, сколько это в абсолютном значении? И сколько это в процентах от общего времени отклика? Покажите мне хоть одно, настолько хорошо написанное предложение, где перфоманс начинают выжимать уже из скоростей переключения контекста!
7 янв 09, 15:36    [6653462]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Zhora
Member

Откуда: USA New York
Сообщений: 402
Выбегалло

...
Дык перешли уже, 9.5. C October 31, 2007 - особых скандалов что-то не слышно.
...

Речь шла о Sybase ASE, в котором BTW до сих пор (at least 12.5) с row-level locking and index ignored dup_key возникают дурацкие deadlocks (оба stmt в errorlog показыает select !) при insert, так что я помню (у меня где-то тонны есть emails) нам пришлось клиенту советовать вернуть все обратно (на APL)...
7 янв 09, 18:14    [6653740]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Выбегалло
Member

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

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


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

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


DB2 ver 9.5 - пример приложения, в котором "перфоманс начинают выжимать уже из скоростей переключения контекста". Иначе с хрена ли бы им переходить на новую архитектуру ?
7 янв 09, 19:25    [6653845]     Ответить | Цитировать Сообщить модератору
 Re: Informix displaces Oracle at China Telcom  [new]
Yo.!
Guest
Выбегалло

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

ну например для того, чтоб не остатся единственной в мире субд работающей через процессы под виндой (где действительно переключения между процессами противоестественно и жутко тормозит).
7 янв 09, 19:49    [6653904]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить