16 октября, вторник 19:42
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Тюнинг MS-Sql 2000

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Тюнинг MS-Sql 2000

    Есть база данных на MS-SQL2000 SP4, работает с ней наш банк-клиент. Пока база была небольшая - все летало. Теперь начинает жутко тормозить.
    Размер файла с БД - около 7Гб, размещен на отдельном дисковом массиве, операционка Windows Server 2003 R2 Enterprise SP1, 2xXeon по 3GHz, 3.5 GB RAM
    Переиндексация таблиц не помогла.
    Может кто сталкивался с подобным делом?

  • #2
    А как делали переиндексацию? Просто пересоздали индексы, или оптимизировали, обрабатывали workload профайлером, и т.д.?

    Комментарий


    • #3
      Uncle Dima Вы не сказали главного - какой именно банк-клиент? От этого очень много зависит.
      И ещё: на этом сервере крутится только СУБД, или какие-то приклады тоже, и файловый шаринг?
      Может, дело-то вовсе не в MSSQL.

      Комментарий


      • #4
        Переиндексацию делали профайлером, он, правда, показал, что и так все в порядке.
        Банк-клиент - iBank2 от Бифита.
        На сервере крутится только СУБД (специально под это дело выделили), стоит файловый шлюз того же iBank2, сервер приложений работает на другой машине.
        Шлюз вроде много не кушает, что с ним, что без него - тормоза одинаковые.

        Комментарий


        • #5
          Много чего может быть. Статистику проверьте чтобы актуальная была. Память лучше не автоматом серверу выделять, а фиксированный объем. Блокировки мониторить...

          Комментарий


          • #6
            Память выделили фиксированную - 3,3ГБайта, реально потребляет меньше - около 1,6. Кстати, SQL-серверу по совету суппорта Бифита оставили 1 процессор, с двумя крыша у него на блокировках ехала. Выдавал много deadlock'ов, иногда и сейчас показывает их.
            Поставил SpotLight, среднее число блокировок на уровне 48=53, ничего критичного не показывает.
            В настройках базы данных - auto update statistics, auto create statistics, auto shrink, torn page detection.

            Комментарий


            • #7
              А логи давно чистили?
              И что по этому поводу говорит Бифит? Может, для таких объёмов MS SQL уже не годится, требуется оракл?

              Комментарий


              • #8
                ax3
                Бифит, конечно, про оракл отзывается более чем хорошо. Еще говорят, что на SQL2005 с дедлоками проблема решится. Но. Для того, чтобы перевести на оракл надо разобраться, в чем проблема, возможно, что ее можно решить и на SQL2000, тем более база не такая уж и большая (7Gb), реально он тянет гораздо больше. Не получится ли, что и на оракле на те же траблы наткнемся?
                А на 2005 перейти - вопрос в том, как. Конверташки нет, получится ли штатными средствами SQL - Бифит точно ответить не может. И поять же, не будет ли тормозить и 2005?

                Комментарий


                • #9
                  Сегодня общался с суппортом БИФИТа, сообщили, что протестировали у себя переход с 2000 на 2005 SQL, прошло без проблем. Что даст точно - решение проблем с deadlock'ами. Буду пробовать на тестовой базе.

                  Комментарий


                  • #10
                    М-да, всё как везде.
                    Узкое место не в СУБД, а скорее всего в прикладе.
                    Я помню ранние версии БСС, они на MSSQL грузили процессоры просто не по-детски, и тормоза были жуть. Поддержка только пожимала плечами. В более поздних сборках проблему таки решили, но осадок остался.

                    Комментарий


                    • #11
                      ax3
                      Наверняка, что-то в этом есть. Последний раз беда была такая: работает шлюз, "перемалывает" входной файл (связка текстовая на данный момент). Тормозит. Выключаем сервер приложений iBank2 - чешет шустро. Включаем - тормозит. И так несколько раз подряд. Помог только полный перезапуск и сервера приложений, и SQL-сервера.
                      Попробую перевести тестовый сервер на SQL-2005, посмотрим, к чему приведет.

                      Комментарий


                      • #12
                        Стоило на неделю уехать в отпуск

                        Уважаемый Uncle Dima!

                        При возникновении тормозов Сервера БД iBank'а в первую очередь запустите на сервере perfmon.exe (прям из командоной строки) и посмотрите загруженность всех подсистем - памяти, процессоров, дисковой подсистемы и пр.

                        Для сервера БД архиважна производительность дисковой подсистемы.

                        Если средняя длина очереди доступа к диску/массиву больше 1 (единицы) - тогда начните с оптимизации дисковой подсистемы.

                        Размер файла с БД - около 7Гб, размещен на отдельном дисковом массиве
                        Если БД iBank'а хранится на отдельном RAID-массиве, то уточните тип RAID-массива. Дело в том, что использовать RAID-5 под БД iBank'а категорически не рекомендуется.

                        Какая-бы у Вас не была числодробилка на RAID-контроллере, вплоть до уровня LSI Logic 320-4x с 512MB кеша, BBU и двумя десятками 15K "шпинделей", итоговый дисковый массив RAID-5 будет безбожно тормозить на операциях записи, показывая около 400..450 IOPS'ов на запись.

                        Дело в том, что в процессе активной работы клиентов (когда создаются, сохраняются, редактуются, подписываются и доподписываются документы) постоянно происходят insert'ы в таблицы БД iBank'а (например, в doc_hist - "история документов"), и соответственно высока нагрузка на запись в дисковую подсистему.

                        Массивы уровня RAID-5 и RAID-6 хорошИ для файловых архивов, файловых серверов с неинтенсивной записью, и для БД с архивными данными с доступом на чтение.

                        В случае же iBank'а настоятельно рекомендуется использовать под БД дисковые массивы уровня RAID-10. При этом каждый современный U320SCSI-диск c 15'000 оборотов в минуту дает в среднем ~350 IOPS'ов, как на запись, так и на чтение.

                        Соответственно, при планировании дисковой подсистемы для сервера БД iBank'а работает правило: "Лучше бОльшее количество маленьких дисков в массиве, чем малое количество больших дисков".

                        Если конкретно, то с точки зрения производительности операций ввода-вывода лучше 8 дисков по 36GB, чем 4 диска по 73GB. Хотя по деньгам варианты практически равны.

                        И естественно, в серверах БД в дисковой подсистеме должны использоваться исключительно высоконадежные и высокопроизводительные U320 SCSI диски с 15'000 rpm.

                        Никаких SATA 7'200 rpm RAID-версий, и даже WD Raptor'ов 10'000 rpm быть не должно. Не те задачи.

                        Свяжитесь в среду со мной по тел. (495) 797-88-89 или аськой 11836139 и обсудим возникшую ситуацию в деталях. Ибо мне не хватает исходных данных.

                        Кстати, SQL-серверу по совету суппорта Бифита оставили 1 процессор, с двумя крыша у него на блокировках ехала.
                        По поводу использования в серверах БД только одного CPU - вообще чушь какая-то. Во многих крупных банках под СУБД (и MSSQL, и Oracle, и Sybase) успешно используются современные промышленные серверы с 4, 8 и более процессорными ядрами, и никаких проблем c несколькими CPU на возникает в принципе.

                        За критический отзыв о работе техподдержки БИФИТа - искреннее огромное спасибо. Будем улучшать!
                        С уважением, Репан Димитрий
                        Компания "БИФИТ" - www.bifit.com

                        Комментарий


                        • #13
                          Димитрий
                          Дело в том, что использовать RAID-5 под БД iBank'а категорически не рекомендуется.
                          У нас БД находится на дисковом массиве HP EVA, сейчас организован как раз RAID5, сделаем 10.
                          По поводу использования в серверах БД только одного CPU - вообще чушь какая-то.... За критический отзыв о работе техподдержки БИФИТа - искреннее огромное спасибо. Будем улучшать!
                          С использованием процессора - именно так и получилось. постоянно вылезали дедлоки, суппорт ломал голову, в итоге посоветовали оставить один процессор. Дедлоки резко уменьшились в количестве, работа более или менее стабилизировалась, хотя тормоза остались. Так что и за такую рекомендацию спасибо.
                          А про отзыв о работе техподдержки - неоднократно упоминал на форумах банкира, что у БИФИТа один из лучших суппортов, какие знаю Поэтому же рекомендовал знакомым покупать iBank, а не что-нибудь другое - и с аналитиками проще общаться, если что-то требуется переделать, и суппорт реагирует сразу и по делу.

                          Комментарий


                          • #14
                            HP EVA - добротный высокопроизводительный девайс, но количество и тип дисков в массиве играет первостепенную роль в производительности.

                            В любом случае прежде чем переконфигурировать RAID-массив, посмотрите perfmon'ом нагрузку на дисковую подсистему сервера с тормозящей СУБД.
                            С уважением, Репан Димитрий
                            Компания "БИФИТ" - www.bifit.com

                            Комментарий


                            • #15
                              А могут быть варианты с некорректными записями в какой-то из таблиц, в результате чего приклад начинает "сходить с ума"?
                              У БССа есть такая фишка с "битыми" пакетами в TransPackets, результат - жуткие тормоза. Убиваешь запись - всё нормально работает. Может быть что-то аналогичное в Бифите?

                              Комментарий


                              • #16
                                А могут быть варианты с некорректными записями в какой-то из таблиц, в результате чего приклад начинает "сходить с ума"?
                                Теоретически может быть всё

                                На практике же подобных вещей (сильно неадекватного поведения ПО в виде жутких тормозов из-за некорректных данных в таблицах БД) ни разу не наблюдалось.
                                С уважением, Репан Димитрий
                                Компания "БИФИТ" - www.bifit.com

                                Комментарий


                                • #17
                                  Димитрий
                                  Стукнулся в аську, поставил счетчики.
                                  Среднее время очереди к диску колеблется около нуля, пики - 0,003
                                  Время записи колеблется на уровне 0,020 - 0,050, временами подскакивает до 0,130.
                                  Загрузка процессора держится на уровне 75%, при этом 25 "жрет" damware, через которую туда подключен. 50% - sql.
                                  Память - в районе 0,000 стр/сек.

                                  В это время идет изменение статусов документов, статусы меняются раз в 2 - 4 секунды, т.е. чтобы отработать 400 документов - приходится очень и очень долго ждать.

                                  Комментарий


                                  • #18
                                    Не те параметры смотрите.

                                    Надо - Performance Objects -> Physical Disk -> Avr. Disk Queue Length

                                    А также отдельно посмотреть Avr. Disk Read Queue Length и Avr. Disk Write Queue Length.

                                    И не вообще по всем дискам, а конкретно для диска, на котором стоит БД iBank'а.
                                    С уважением, Репан Димитрий
                                    Компания "БИФИТ" - www.bifit.com

                                    Комментарий


                                    • #19
                                      Димитрий
                                      Надо - Performance Objects -> Physical Disk -> Avr. Disk Queue Length Именно его и поставил - среднее время очереди - 0,003
                                      Avr. Disk Read Queue Length и Avr. Disk Write Queue Length.
                                      Avr. Disk Write Queue Length - 0,001 - 0,008
                                      Avr. Disk Read Queue Length - 0,001 - 0,006
                                      Все стоит по конкретному диску с БД.

                                      Комментарий


                                      • #20
                                        Все. Завис сервер приложений. Процессы при этом: идет выгрузка документов, уже три минуты в лог ничего не пишется. При этом все очереди чтения-записи по нулям. загрузка процессора - минимальная.
                                        Останавливаю сервер приложений - зашуршал шлюз, продолжается выгрузка документов. Запускаю СП - продолжается выгрузка документов.
                                        Т.е. складывается впечатление, что СП в какой-то момент "подвешивает" БД.

                                        Комментарий


                                        • #21
                                          Именно его и поставил - среднее время очереди - 0,003
                                          Правильнее сказать "средняя длина очереди".

                                          Приведенные Вами цифры говорят по полной ненагруженности дисковой подсистемы. То есть проблема явно не в дисковом массиве.

                                          Uncle Dima, позвоните в БИФИТ, попросите секретаря связать со мной и я переключу на разработчика, который непосредственно будет разбираться с Вашим случаем. Или в аську мне постучите.
                                          С уважением, Репан Димитрий
                                          Компания "БИФИТ" - www.bifit.com

                                          Комментарий


                                          • #22
                                            Сообщение от Uncle Dima Посмотреть сообщение
                                            Все. Завис сервер приложений. Процессы при этом: идет выгрузка документов, уже три минуты в лог ничего не пишется. При этом все очереди чтения-записи по нулям. загрузка процессора - минимальная.
                                            Останавливаю сервер приложений - зашуршал шлюз, продолжается выгрузка документов. Запускаю СП - продолжается выгрузка документов.
                                            Т.е. складывается впечатление, что СП в какой-то момент "подвешивает" БД.
                                            Это - в поддержку Бифита, однозначно. Здесь Вам никто удалённо диагноз не поставит.

                                            Комментарий


                                            • #23
                                              Димитрий
                                              Наши админы сообщили, что для EVA все равно, какой указать массив, 5 или 10 уровня, это влияет лишь на опознание его операционкой. Дисковой же подсистемой рулит сама EVA, причем шустрее, чем она это делает, заставить работать массив невозможно.
                                              Девайс HP EVA 5000 3,5TB

                                              Комментарий


                                              • #24
                                                Наши админы сообщили, что для EVA все равно, какой указать массив, 5 или 10 уровня, это влияет лишь на опознание его операционкой. Дисковой же подсистемой рулит сама EVA, причем шустрее, чем она это делает, заставить работать массив невозможно.
                                                Категорически не согласен с таким заявлением. Пусть админы поиграются с IOmeter'ом и соберут статистику. Тогда они поймут почему важен и уровень RAID'а, и количество шпинделей, и типы используемых дисков.

                                                Но всё это - не в тему топика. Да и уже неактуально - perfmon с Ваших слов показал, что нагрузка на дисковую подсистему практически отсутствует (то есть текущей конфигурации HP EVA 5000 хватает за глаза).

                                                Сейчас наши разработчики совместно с Вами собирают статистику и после анализа - будем выявлять истинную причину возникающих тормозов.
                                                С уважением, Репан Димитрий
                                                Компания "БИФИТ" - www.bifit.com

                                                Комментарий


                                                • #25
                                                  Димитрий
                                                  Включил счетчик блокировок SQL. Снял скриншот с perfmon.
                                                  Кажется, нереально много блокировок.

                                                  Комментарий


                                                  • #26
                                                    Дело оказалось не в железе и не в SQL. Слетел первичный ключ с таблицы платежек, возможно, что еще чего-то не так в базе.
                                                    Спасибо БИФИТУ, проблема решается. Уже "летает" выгрузка документов и обработка статусов (388 документов за 25 сек). Остается разобраться с тормозами при загрузке выписок.

                                                    Еще раз упомяну, что суппорт у БИФИТа один из лучших и проблемы именно решает, а не делает вид, что что-то ищет (бывают и такие конторы, знаю не по наслышке).

                                                    Комментарий


                                                    • #27
                                                      Тоже немного не в тему топика, но .. как бывшему суппортёру БСС и теперешнему НРшнику, отмечу что для EVA уровень RAID влияет на производительность, 5 конечно медленнее 10 ,
                                                      но зависимость не такая явная как для классических райдов,т.к. по умолчанию любой уровень рэйда распределяется по всем шпинделям.админы конечно не правы,просто скорее всего производительности на 5м райде тоже хватает.

                                                      Комментарий

                                                      Пользователи, просматривающие эту тему

                                                      Свернуть

                                                      Присутствует 1. Участников: 0, гостей: 1.

                                                      Обработка...
                                                      X