Производительность, прокомментируйте, пожалуйста

[bbeeaa]

Вот такую инфу нашел в сети:

При увеличении размера базы данных производительность сервера вполне прогнозируемо снижается. Использование многоядерных и/или многопроцессорных серверных архитектур мало помогает в решении данной проблемы, так как основным узким местом СУБД Firebird является обмен данными с жестким диском. Сервер классической архитектуры позволяет загрузить несколько ядер/процессоров одновременно и в общем случае дает лучший отклик при большом количестве пользователей, но имеет существенный недостаток — маленький размер буфера записей. Так, на сервере с 4 Гб оперативной памяти, к которому одновременно подключается 60-70 пользователей, максимальный размер буфера не должен превышать 20 Мб, что ничтожно мало при работе с 8-10 гигабайтной базой данных. Суперсервер позволяет использовать кэш размером в 1 Гб и более, но выполняется только на одном процессоре. К тому же, падение серверного процесса обрывает все активные подключения. Фактически, у наших клиентов с базами в 5 Гб и более и количеством одновременных коннектов в 30-40 и выше, низкая скорость работы системы является одной из основных претензий.

Насколько это соответствует действительности. Действительно ли при 30-40 подключениях скорость Firebird катастрофически падает? Всё ли верно про кеш?

[Merlin]

Бред сивой кобылы в тёплую январскую ночь. За исключением того, что а) в классике действительно нужно считать RAM, и не только по причине физического ограничения его объёма, а определять хороший размер кеша для конкретной задачи экспериментально б) при падении супера естественным образом падают все соединения.

[WildSery]

у наших клиентов с базами в 5 Гб и более и количеством одновременных коннектов в 30-40 и выше, низкая скорость работы системы является одной из основных претензий.

А у наших - не является. Даже с гораздо большей базой, большим числомм коннектов и к тому же ещё основной клиент на BDE написан, практически без управления транзакциями.

[bbeeaa]

Спасибо, а то я уже испугался, похоже, у кого-то проблемы в консерватории.

[kdv]

так скажите, у кого там проблемы с производительностью. в смысле, откуда цитата?

[kdv]

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

[andreik]

Çàïðîñû, êîòîðûå Ãåäûìèí îòñûëàåò íà ñåðâåð, ìîæíî óñëîâíî ðàçäåëèòü íà òðè êàòåãîðèè:
1. èçâëå÷åíèå ñèñòåìíîé èíôîðìàöèè, íåîáõîäèìîé äëÿ ôóíêöèîíèðîâàíèÿ ïëàòôîðìû: ïðîãðàììíûé êîä, îò÷åòû, ýêðàííûå ôîðìû, íàñòðîéêè ïîëüçîâàòåëüñêîãî èíòåðôåéñà, ïðî÷àÿ èíôîðìàöèÿ, êîòîðàÿ ìîæåò ïîíàäîáèòüñÿ ïëàòôîðìå â ïðîöåññå åå äåÿòåëüíîñòè;
2. ÷òåíèå è ìîäèôèêàöèÿ äàííûõ (âñòàâêà, èçìåíåíèå, óäàëåíèå);
3. èçâëå÷åíèå äàííûõ äëÿ ïîñòðîåíèÿ àíàëèòè÷åñêèõ îò÷åòîâ.

Çàïðîñû ïåðâîé êàòåãîðèè êðèòè÷íû äëÿ ôóíêöèîíèðîâàíèÿ ïëàòôîðìû, ïîýòîìó äàííàÿ èíôîðìàöèÿ íàñêîëüêî âîçìîæíî êýøèðóåòñÿ íà ëîêàëüíîì äèñêå è ñ÷èòûâàåòñÿ èç áàçû òîëüêî â ñëó÷àå èçìåíåíèÿ åå äðóãèì ïîëüçîâàòåëåì.

Çàïðîñû âòîðîé êàòåãîðèè ñîñòàâëÿþò ïðîöåíòîâ 99% îò îáùåãî êîëè÷åñòâà çàïðîñîâ, âûïîëíÿåìûõ ñåðâåðîì. Îòêðûëè íà ýêðàíå îêíî ñî ñ÷åòàìè ôàêòóðàìè, ââåëè è ñîõðàíèëè íàêëàäíóþ, ñîçäàëè íîâóþ ó÷åòíóþ çàïèñü êëèåíòà è ò.ï. – âñå ïðèâîäèò ê ÷òåíèþ èëè ìîäèôèêàöèè äàííûõ.

È, íàêîíåö, òðåòüÿ êàòåãîðèÿ – çàïðîñû íå ñòîëü ÷àñòûå, íî ïî ïðèðîäå ñâîåé äîëãîâðåìåííûå, ïîñêîëüêó ïðèâîäÿò ê ÷òåíèþ, îáúåäèíåíèþ è ãðóïïèðîâêå èíôîðìàöèè èç òàáëèö ïî 10-15 ìëí. çàïèñåé.

×òî ñ÷èòàòü ïðèåìëåìûì áûñòðîäåéñòâèåì? Åñëè îïåðàòîð ââîäèò íàêëàäíóþ, êîòîðàÿ ëåæèò ïåðåä íèì ðàñïå÷àòàííàÿ íà áóìàãå, òî çàäåðæêà â 5-10 ñåê, íàïðèìåð, ïðè âûáîðå ïîçèöèè íå ñóùåñòâåííà. Ñ ýòèì ìîæíî æèòü. Äðóãîå äåëî, êîãäà ñîòðóäíèê îòäåëà ìàðêåòèíãà, ñêàæåì ìÿñîêîìáèíàòà, ïðèíèìàåò ïî òåëåôîíó çàÿâêó îò òîâàðîâåäà ìàãàçèíà. Òóò, ñîãëàñèòåñü, äàæå 2-3-õ ñåêóíäíàÿ çàäåðæêà íà êàæäîé èç 20-30 ïîçèöèé óæå áóäåò ðàçäðàæàòü ÷åëîâåêà.

 íàøåé ïðàêòèêå ìû èìååì áîëåå äåñÿòêà áàç íà ðàçíûõ ïðåäïðèÿòèÿõ ðàçìåðîì â ðàéîíå 10 Ãá è êîëè÷åñòâîì îäíîâðåìåííûõ ïîäêëþ÷åíèé ñâûøå 30-35. Åñëè èäåò ïðîñòî ââîä èíôîðìàöèè, òî äîñòàòî÷íîãî áûñòðîäåéñòâèÿ Interbase ïîçâîëÿåò äîñòèãíóòü äàæå íà ïîñðåäñòâåííîì æåëåçå. Ïðè÷åì, èñïîëüçîâàíèå àðõèòåêòóðû ñóïåð-ñåðâåð â ñîâîêóïíîñòè ñ áîëüøèì ðàçìåðîì êýøà, â äàííîì ñëó÷àå ïîçâîëÿåò äîñòè÷ü ëó÷øèõ ðåçóëüòàòîâ. Ïðîáëåìû âîçíèêàþò, êîãäà ê 30 îïåðàòîðàì, íàáèðàþùèì íàêëàäíûå, äîáàâëÿþòñÿ îäèí-äâà, êîòîðûå çàïóñêàþò íà âûïîëíåíèå äîëãîèãðàþùèå çàïðîñû.  òå÷åíèå 20-30 ìèíóò, ïîêà íå ïîñòðîÿòñÿ àíàëèòè÷åñêèå îò÷åòû, âñå ïîëüçîâàòåëè ñèñòåìû èñïûòûâàþò íåóäîáñòâà. Âðåìÿ îòêëèêà ïðè ââîäå ïîçèöèè äîêóìåíòà ìîæåò âîçðàñòè ñ 5-6 ñåêóíä, äî 50-60, ÷òî, ñîãëàñèòåñü, íåïðèåìëåìî.

Äàííàÿ ïðîáëåìà èìååò íåñêîëüêî ðåøåíèé, êàæäîå èç êîòîðûõ îáëàäàåò ñâîèìè îãðàíè÷åíèÿìè. 1) Ìîæíî îðãàíèçàöèîííî çàïðåòèòü ïîñòðîåíèå àíàëèòè÷åñêèõ îò÷åòîâ â ÷àñû íàèáîëüøåé íàãðóçêè íà ñåðâåð. Ïðè ýòîì ñðàçó âîçíèêíóò íåäîâîëüíûå ñîòðóäíèêè, êîòîðûì êîíêðåòíûé îò÷åò íóæåí çäåñü è ñåé÷àñ. 2) Ìîæíî ðàçäåëèòü áàçó íà äâå, àíàëèòè÷åñêóþ è îïåðàòèâíóþ. Íî, ïðè ýòîì åñòåñòâåííî ïîñòðàäàåò åäèíîå èíôîðìàöèîííîå ïðîñòðàíñòâî ïðåäïðèÿòèÿ. 3) Ìîæíî ïîïûòàòüñÿ ñîçäàòü êëàñòåðíîå ðåøåíèå íà óðîâíå êîìïîíåíòîâ äîñòóïà ê ñåðâåðó äëÿ òîãî, ÷òîáû ðàçíåñòè äîëãîèãðàþùèå çàïðîñû ïî ðàçíûì êîìïüþòåðàì. 4) È, íàêîíåö, ìîæíî ïðèîáðåñòè ñâåðõäîðîãîå æåëåçî…

Åñëè âû äî÷èòàëè äî ýòîãî ìåñòà, òî ðåçþìå òàêîå: Interbase/Firebird ñïîñîáåí îáåñïå÷èòü äîñòàòî÷íóþ ïðîèçâîäèòåëüíîñòü äàæå íà áàçàõ ðàçìåðîì áîëåå 10 Ãá è äàæå ïðè ìíîãèõ äåñÿòêàõ îäíîâðåìåííûõ ïîäêëþ÷åíèé, ïîêà ðå÷ü èäåò îá èçâëå÷åíèè è ìîäèôèêàöèè èíôîðìàöèè. Åñëè íà âõîä ñåðâåðà ïîñòóïèò çàïðîñ, èëè ïî ïðèðîäå ñâîåé äëèòåëüíûé, èëè ïðîñòî íàïèñàííûé êîðÿâî, òî âñå ïîëüçîâàòåëè, íåñîìíåííî, ýòî ïî÷óâñòâóþò…

PS: Êîðåíü äàííîé ïðîáëåìû â òîì, ÷òî â Interbase íåëüçÿ óêàçàòü ïðèîðèòåò çàïðîñà. Åñëè áû ìîæíî áûëî íàñòðîèòü àíàëèòè÷åñêèå çàïðîñû òàê, ÷òîáû îíè âûïîëíÿëèñü â òå ìîìåíòû âðåìåíè, êîãäà ñåðâåð íå çàãðóæåí äðóãîé ðàáîòîé, òî íàðåêàíèé íà áûñòðîäåéñòâèå áûëî áû íà ïîðÿäîê ìåíüøå…

[Merlin]

В нашей практике мы имеем более десятка баз на разных предприятиях размером в районе 10 Гб и количеством одновременных подключений свыше 30-35. Если идет просто ввод информации, то достаточного быстродействия Interbase позволяет достигнуть даже на посредственном железе. Причем, использование архитектуры супер-сервер в совокупности с большим размером кэша, в данном случае позволяет достичь лучших результатов. Проблемы возникают, когда к 30 операторам, набирающим накладные, добавляются один-два, которые запускают на выполнение долгоиграющие запросы. В течение 20-30 минут, пока не построятся аналитические отчеты, все пользователи системы испытывают неудобства. Время отклика при вводе позиции документа может возрасти с 5-6 секунд, до 50-60, что, согласитесь, неприемлемо.

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

4) И, наконец, можно приобрести сверхдорогое железо…

Сверхдорогое - это сколько? Наша системка примерно в описанном классе, чутка тяжелее, но не суть. Серверное железо стоило года полтора назад около 10 килобаксов. И покупалось не потому, что хотелось большого и светлого, а просто потому, что сдохло предыдущее, купленное примерно за ту же сумму в 2000 году, производительность-то в общем и целом устраивала. Это сверхдорого?

Если вы дочитали до этого места, то резюме такое: Interbase/Firebird способен обеспечить достаточную производительность даже на базах размером более 10 Гб и даже при многих десятках одновременных подключений, пока речь идет об извлечении и модификации информации. Если на вход сервера поступит запрос, или по природе своей длительный, или просто написанный коряво, то все пользователи, несомненно, это почувствуют…

Во-первых, среди перечисленных решений отсутствует самое очевидное и работоспособное, а именно - не упираться в супер, а взять классику и настроить размер кеша на рабочей нагрузке (это с целью оптимизировать именно время отклика в его первозданном значении). И никто ничего не почувствует. Разумеется, если корявые запросы только в АРМ-ах пары-тройки аналитиков, а не у всей дивизии поголовно, начиная с уборщицы Комментировать рассуждения насчёт 20мб кеша, ничтожно мало и так далее относительно классики, я уж не буду из сострадания к заслуженному бойцу, ладно? Если чего-то не знаешь, лучше про это не писать, ей-богу. А если не умеешь с ней (классикой) обращаться, то стоит разобраться и научиться

PS: Корень данной проблемы в том, что в Interbase нельзя указать приоритет запроса. Если бы можно было настроить аналитические запросы так, чтобы они выполнялись в те моменты времени, когда сервер не загружен другой работой, то нареканий на быстродействие было бы на порядок меньше…

Во-вторых, корень данной проблемы сосвсем не в этом, а в том, что нити супера хреново распараллеливаются по процессорам в большинстве версий IB/FB. А снижением втупую, не динамически, приоритетов долгоиграющих запросов загнать сервер в задницу как раз гораздо проще, чем повысить быстродействие. Особенно если долгоиграбельность из-за сборки мусора. Прежде чем тосковать по сомнительной фиче, полезной в руках считанных единиц мастеров рукопашного боя, я бы, как всегда, посоветовал почитать про динамическое управление приоритетами, скажем, в операционных системах. И задуматься для начала - а почему оно такое разное в разных осях и их версиях

[WildSery]

Добавлю свои 5 копеек.
Наши базы работают на серверах стоимостью примерно 5К а то и меньше, раза в полтора больше объёмом, по пользователям - в два.
Никакие "суперотчёты" никого не напрягают, кроме самих страждущих получить эти отчёты. Потому как линух + классик + 2-4 ядра процев рулят.
Кстати, АСУ написано в основном левой ногой, так что ещё и оптимизировать работу можно ого-го как.

[andreik]

îê. åñëè âû ñ÷èòàåòå, ÷òî ó ÈÁ/ÔÁ íåò íèêàêèõ ïðîáëåì ñ ïðîèçâîäèòåëüíîñòüþ, òî ïóñòü áóäåò òàê.

[WildSery]

ок. если вы считаете, что у ИБ/ФБ нет никаких проблем с производительностью, то пусть будет так.

Ок. Если ты считаешь, что проблемы с производительностью именно из-за IB/FB, то пусть будет так

[stix-s]

ок. если вы считаете, что у ИБ/ФБ нет никаких проблем с производительностью, то пусть будет так.

Проблемы, безусловно, есть у всех СУБД
но почему вы, ребята, коль считаете, то на IB/FB проблемы, почему на другую СУБД не переходите?

[andreik]

Íà ÔÁ ðàáîòàåì ïîòîìó, ÷òî îí áåñïëàòíûé. Ïðîáëåìû, è ïðè òîì ðàçíûå, äåéñòâèòåëüíî åñòü ó âñåõ. Ìû âñåãî ëèøü ïûòàåìñÿ íàéòè ðåøåíèå íàøåé êîíêðåòíîé ïðîáëåìû, â íàøåì êîíêðåòíîì ñëó÷àå.

[Merlin]

ок. если вы считаете, что у ИБ/ФБ нет никаких проблем с производительностью, то пусть будет так.

Проблемы, безусловно, есть у всех СУБД
но почему вы, ребята, коль считаете, то на IB/FB проблемы, почему на другую СУБД не переходите?

Этта... Отставить наезды. Ребята с FB работали когда некоторые критиканы ещё пешком под стол ходили. И разработка у них серьёзная. Про классику вот херню написали, это да. Собственный страничный кеш FB вообще нужен для достаточно специфических вещей, главным образом при работе с индексами. А база как таковая прекрасно кешируется файловой системой по мере возможности и потребности. 75 умолчательных страниц кеша FB для классики, вообще-то, для баз со сложной схемой метаданных, маловато, но и раздувать его сильно тоже вредно и тем вредней, чем выше интенсивность изменений - кеши-то процессов синхронизировать надо. У нас оптимум в диапазоне 1024-2048 страниц на процесс, у нас модификаций гораздо меньше, чем чтений. А страшные мегабайты RAM под процесс - это не кеши, а BLR и данные вызванных SP и тому подобное, типа стеки-хипы, к кешу это отношения не имеет. Чудненько освобождается на коммитах, но иметь в виду, причём характерные размеры для своих конкретных задач, чтоб не улетать в своп, надо. Пресловутое время отклика у супера по-любому будет чутка получше, даже при сравнении монопольного доступа, но это далеко не секунды

[stix-s]

Этта... Отставить наезды.

если это в мой огород камень, то даже и не пытался, просто интерес.
сорь, если неправильно выразился

[Dimitry Sibiryakov]

2) Можно разделить базу на две, аналитическую и оперативную. Но, при этом естественно пострадает единое информационное пространство предприятия.

Дед обиделся за классика, а я вступлюсь за репликацию: что за вред для "единости" информационного пространства Вы имеете ввиду? То, что аналитические запросы придется посылать по другому коннекту? Это гораздо проще "кластерного решения на основе компонентов доступа".