Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:
А>>banderlog & agronom
S>Кошмар ребята. Просто кошмар. Вы что, всерьез полагаете, что добавление второго процессора способно замедлить работу interbase? И за счет чего, интересно? Да еще и количество обращений к винту радикально увеличить... Я вам настоятельно рекомендую купить какую-нибудь книжку про разработку СУБД и прочитать хотя бы бегло.

Мысль хорошая. Доки, книги — вещь полезная. Вот и глянь книгу. И почитай бегло. Здесь спор идет о FIB, а не о СУБД вообще. КАрочИ — еще с 1 FIB была такая фигня. Если посмотреть на то, какие баги исправлялись при разработке 1.5, то в доке ни слова нет о многопроцессорности.

iT>Если ты не видишь разницы между содержательностью ответа "смотри доки" и "смотри планы" — могу только посочувствовать. 50 тыс а под 1.5 500 млн!! Ты посмотри насколько происходит увеличение, и ты хочешь это лечить настройкой плана?! Вот пытаюсь разглядеть разницу и никак не вижу.

Здравствуйте, Igor Trofimov, Вы писали:

iT>Я старался.
Ну это понятно, к интернету коннестился клоун

iT>Если ты не видишь разницы между содержательностью ответа "смотри доки" и "смотри планы" — могу только посочувствовать.
Разница, не в том, что смотреть, а в том какой ты дал ответ. Ты вот иди и смотри.......

iT>Но в первую очередь надо бы проверить планы.
Еще раз тебе говорю дело тут не в планах слишком большая разница в количестве обращений 50 тыс и 500 млн!!

А>>FireBird SuperServer не поддерживает работу на двухпроцесорных машинах. Для правильной работы нужно работать на одном процессоре(принудительно указать серверу один процессор) или устанавливать interbase 7.0 или использовать архетектуру классик.

Да, вижу ты уж точно доку не читал

Здравствуйте, Аноним, Вы писали:

А>Да, вижу ты уж точно доку не читал

Здравствуйте, Alex.Che, Вы писали:
AC>А что ты знаешь "...об устройстве операционных систем", отличных от MS Windows?
Да практически ничего. Но основная идея любых систем с вытесняющей многозадачностью вроде как в том, что шедулер время от времени сбрасывает контекст единицы шедулинга (будь то процесс или поток) в память, выбирает другой контекст, и поднимает в процессор его для исполнения в течение следующего кванта.
Отличие поддержки нескольких процессоров в том, что шедулер может назначить одновременно N потоков/процессов на исполнение.
Очевидно, что приложение, которое выполняет всю свою работу в пределах одной единицы шедулинга, не сможет использовать более одного процессора одновременно.
Но вот почему шедулинг при количестве процессоров более 1 становится настолько медленнее, я не понимаю. То есть насколько я знаю, при восстановлении контекста в момент активации потока шедулер выбирает, куда его восстановить.
Единственная идея, которая приходит мне в голову, состоит в том, что при восстановлении контекста в тот же процессор, где он был, есть шанс использовать кэш этого процессора. Я не в курсе, как взаимодействует кэширование в современных процах с переключениями контекста, поэтому не могу делать осмысленных заключений.
Тем не менее, не вижу повода как-то радикально просаживать производительность в этом случае (кроме того, почему бы не учитывать кэширование в шедулере?)

Привет, Sinclair!
Вы пишешь 16 апреля 2004:

AC>> А что ты знаешь "...об устройстве операционных систем", отличных от MS Windows?
S> Да практически ничего. Но основная идея любых систем с вытесняющей многозадачностью...

А теперь ещё раз прочти, то что я написал, про то, когда и под что разрабатывался IB

--
With best regards, Alex Cherednichenko.

Здравствуйте, Sinclair, Вы писали:

S>Очевидно, что приложение, которое выполняет всю свою работу в пределах одной единицы шедулинга, не сможет использовать более одного процессора одновременно.
S>Но вот почему шедулинг при количестве процессоров более 1 становится настолько медленнее, я не понимаю. То есть насколько я знаю, при восстановлении контекста в момент активации потока шедулер выбирает, куда его восстановить.

Если бы это было так, то ядра систем с поддержкой SMP и без нее не различались. Все дело в том, что вытесняющая многозадачность поддерживается самим процессором. Если упростить, процессор сам по команде сохраняет состояние регистров (где — не суть важно), берет регистры другого потока и прололжает... Причем здесь не интересно, какоим процессам принадлежат потоки.
А вот при друх процессорах уже все сложнее, ядру приходится отнимать у одного процессора весь процесс вместе с потоками и переносить на другой. А это уже гораздо напряжнее.

Здравствуйте, glyph, Вы писали:

C>>Бекапил-ресторил не помогает. А можешь поподробнее? У мея в конторе не один программер не знает что есть DNA.
C>>Вообщето настройкой серверов мы только только занялись.
G> 8) DNA == ДНК.

DNA — distributed network applications, e.g. Windows DNA

Здравствуйте, Alex.Che, Вы писали:

AC>А теперь ещё раз прочти, то что я написал, про то, когда и под что разрабатывался IB
Блин, да какая разница? Я говорю про произвольное приложение. Откуда берутся накладные расходы при втором процессоре?
З.Ы. Я догадываюсь, почему IB не умеет использовать больше 50% от двух процессоров и 25% от четырех. Вопрос не в этом.

Здравствуйте, <Аноним>, Вы писали:

iT>>Но в первую очередь надо бы проверить планы.
А>Еще раз тебе говорю дело тут не в планах слишком большая разница в количестве обращений 50 тыс и 500 млн!!
Я восхищаюсь упорством храбрых. Вот мой опыт показвает, что увеличение количества обращений на 10 в четвертой зависит исключительно от плана запроса. Для тех, кто в танке, поясняю — если мы используем индекс, то читаем только необходмиый минимум. А если в плане стоит table scan — то придется читать все. Вот и получаем увеличение чтений ровно во столько раз, сколько была селективность индекса. А для джойнов ошибка в подборе плана может сыграть еще более радикальную роль. Ты бы вместо того, чтобы наезжать на Игоря привел сюда план запроса на FB1 и его же план на FB1.5.