locked
Зависание системы RRS feed

  • Вопрос

  • Добрый день. Конфигурация: ос сервер 2008R2, xeon e3 1230, 32Gb ОЗУ. lsi raid 2008 - raid 10. Подключен бэкапный юсб диск (D).

    На сервере крутится sql 2008 (выделено 16Гб ОЗУ), сервер 1С. Также работает как сервер терминалов для троих человек. Сегодня сервер завис. Точнее в начале стал еле работать, далее перестал запускать пользователей в 1С, потом просто перестал отвечать по сети. Пробудить локально сервер не получилось, на клавиатуру-мышь не реагировал. А вот активность дисков, судя по светоиндикатору дисков - была.  Перегрузил сервер жестко. После перезагрузки включилась проверка дисков, далее система заработала в нормальном режиме. Стал смотреть ошибки. В системных событиях из последних: 

    Предыдущее завершение работы системы в 9:15:55 на ‎04.‎12.‎2015 было неожиданным. - Это жестко перегрузили сервер.

    Предупреждение: 04.12.2015 4:29:29 Ошибка выделения рабочего стола из кучи.

    03.12.2015 4:01:47 Код 7011. Превышение времени ожидания (30000 мс) при ожидании ответа транзакции от службы "Appinfo".

    02.12.2015 15:35:41 источник: Disk. Драйвер обнаружил ошибку контроллера \Device\Harddisk1\DR3. 

    Глубже смотреть, наверно, нет смысла. Совсем далеко. 

    \Device\Harddisk1\DR3 - я так понимаю, это у меня внешний USB накопитель. SQL архивации баз на него идут каждые два часа в рабочее время и один раз ночью - в не рабочее.  Так же есть ночная архивация всего диска акронисом на сетевой ресурс.

    Теперь по событиям приложений. Критические: 

    Эта ошибка повторяется пять раз.

    04.12.2015 9:07:09 Источник MSSQLSERVER, Код 18210, Категория Резервное копирование, 

    BackupIoRequest::ReportIoError: ошибка write на устройстве резервного копирования "D:\sql baaackuuuup\-\upp_20150811_backup_2015_12_04_090036_3055553.bak". Ошибка операционной системы 2(Не удается найти указанный файл.).

    -----------------------------

     Далее:

    04.12.2015 9:11:58 Код 3000 APCPBEAgent "Lost Communication With UPS" 

    ----------------------------

    04.12.2015 9:12:57 Код 1000

    Имя сбойного приложения: WINWORD.EXE, версия: 15.0.4763.1000, отметка времени: 0x55f7f1af
    Имя сбойного модуля: KERNELBASE.dll, версия: 6.1.7601.19018, отметка времени 0x5609fed4
    Код исключения: 0xe0000002
    Смещение ошибки: 0x0000c42d
    Идентификатор сбойного процесса: 0x448c
    Время запуска сбойного приложения: 0x01d12daf267ecfe6
    Путь сбойного приложения: C:\Program Files (x86)\Microsoft Office\Office15\WINWORD.EXE
    Путь сбойного модуля: C:\Windows\syswow64\KERNELBASE.dll
    Код отчета: 0f5e7db1-9a4e-11e5-8f23-60a44c2485d3

    -----------------------------------------------

    Все. 

    Может ли причина зависания быть в неисправности внешнего накопителя? Либо сбоя самого SQL? Жду любые предложения.

    4 декабря 2015 г. 7:46

Ответы

  • Да, это вариант. Только вот включать кэш в RAID-контроллере желательно при наличии батарейного резервирования (наверное, не зря его контроллер включать не позволял). А то так можно базу убить при внезапном пропадании питания.

    Другое дело, что у автора нагрузка совсем не такая, как у вас.


    Слава России!

    6 декабря 2015 г. 10:59
  • Да, этого должно быть достаточно. Лишь бы питание не было отключено мгновенно.
    7 декабря 2015 г. 6:46

Все ответы

  • Для начала попробуйте оценить производительность системы. Запустите системный монитор Windows, и посмотрите нагрузку, в первую очередь стоит обратить внимание на счетчики:

    Процесс(_Total)\Байт исключительного  использования

    Физический Диск\Средняя длина очереди

    Процессор(_total)\% загруженности процессора.

    Уточните, сколько дисков у вас в массиве RAID?

    Оцените производительность дисков с помощью SQLIO

    4 декабря 2015 г. 9:18
  • 4 диска 

    Сколько счетчику работать?

    • Изменено ivldenis1 4 декабря 2015 г. 13:57
    4 декабря 2015 г. 13:53
  • Не выключайте пока с не будете уверены что проблема решена. Вообще хорошо, их снимать постоянно, и складывать в БД SQL. SQL Express 2008 R2, хватит с головой для этих целей. Зато у Вас под рукой всегда будет статистическая информация для анализа производительности. Не используйте счетчики скорость записи на диск, скорость чтения с диска, они могут ухудшать производительность.

    Проверьте включен ли у вас кэш записи на дисках. Свойства диска->Оборудование->Политики. Это значительно повышает скорость записи. Некоторые RAID-массивы, имеют, неудовлетворительную скорость записи, в частности RAID1, RAID10 тоже, хотя лучше чем 1. Скачайте и запустите SQLIO со следующими параметрами и скажите результаты.

    SQLIO -kW -frandom -b4 -s300 -dC(здесь С - это диск на кортом у вас система)

    только не запускайте в рабочее время

    Кэш записи диска может быть не доступен, если на RAID-контроллере нет дополнительного питания, операционная система вам об этом сообщит.

    4 декабря 2015 г. 14:38
  • Предупреждение: 04.12.2015 4:29:29 Ошибка выделения рабочего стола из кучи.

    ...

    Может ли причина зависания быть в неисправности внешнего накопителя? Либо сбоя самого SQL? Жду любые предложения.

    Предупреждение намекает на утечку памяти из пулов ядра. Конечно, в 64-битных системах нет тех жёстких ограничений на размеры пулов, что были в 32-битных, но всё же ограничения есть, особенно - для неподкачиваемого пула: он постоянно размещён в оперативной памяти, а потому не может превосходить её размеров.

    Промониторьте размеры пулов памяти ядра либо вручную через вкладку Быстродействие Диспетчера задач, либо через соответствующие счётчики в разделе Память Системного монитора. Если обнаружите утечку - монотонный неограниченный рост - то источник утечки можно поискать с помощью утилиты poolmon, которую для 64-битныз систем можно найти в комплекте средств разработки драйверов Windows (они свободно скачиваются с сайта MS).


    Слава России!

    4 декабря 2015 г. 14:42
  • Кэш отключен, но вроде как софт контроллера позволяет это сделать, правда с предупреждением о возможности потери данных при сбое питания. Доп.питания на контроллере нет . В выходные сделаю тестирование. Отпишу.
    • Изменено ivldenis1 4 декабря 2015 г. 15:07
    4 декабря 2015 г. 14:53
  • sqlio v1.5.SG
    1 thread writing for 300 secs to file C:testfile.dat
            using 4KB random IOs
    using current size: 734 MB for file: C:testfile.dat
    initialization done
    CUMULATIVE DATA:
    throughput metrics:
    IOs/sec:   112.15
    MBs/sec:     0.43
    5 декабря 2015 г. 16:45
  • Как и ожидалось, у вас чудовищно низкая производительность диска. Ваш сервер выполняет сразу несколько ролей, и сервер БД и сервер приложений, это не есть гуд. Для начала включите кеш записи, если вы говорите что у Вас эта опция доступна. Через минут 5 запустите SQLIO, она должна показать совершенно другие результаты.

    Если у вас бывают ситуации с отключением питания и вы боитесь потери данных, то разберите RAID, два диска отставьте в зеркале для хранения данных, а оставшиеся для работы операционной системы и приложений Не объединенные в массив, с включенным кэшем записи они будут работать значительно быстрее. Если позволяет контроллер RAID, оставшиеся диски можно объединить в страйп.

    Лучшим вариантом будет разнести роли по разным серверам, если возможно. Приложения отдельно, данные отдельно.


    6 декабря 2015 г. 6:06
  • Где вы увидели чудовищно низкую производительность диска?

    100 IOPS - это вполне себе приличная производительность для случайного (random) ввода-вывода, обычно именно таковой ориентировочно считают производительность одного SAS-диска со скоростью вращения 10K rpm, или производительность на запись RAID1 из двух таких дисков (в зеркале, как известно производительность записи равна производительности одного диска). И если у автора RAID10 собран из 4-х SATA 7200rpm, то измеренная производительность вполне близка к номинальной, снижение может быть связано с тем, что тест неравномерно использует полосы на разных дисках.

    На скорость чтения в тесте Random I/O не смотрите: она показательна для линейного чтения/записи, но не для случайного, где она равна числу IOPS, помноженному на размер блока (увеличьте размер блока до 64КБайт - и будет вам счастье в виде скорости чтения 6,5 МБайт/с).

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


    Слава России!



    • Изменено M.V.V. _ 6 декабря 2015 г. 8:37
    6 декабря 2015 г. 8:28
  • Я сужу исходя из личного опыта, так как сталкивался с похожей проблемой лично, имелось ферма терминальных серверов под Citrix XenApp, на IBM HS23 с RAID1, в определенный период при достижении пиковых нагрузок, сервера стали наглухо зависать, было выявлено, что скорость записи на дисках с отключенным кэшем была в районе 300 iops и 0,5-0,7 mbs/s. Кэш записи не давал включить контроллер RAID. Средняя очереди диска была в район 8-12. Для массива из 2-х дисков это много. Искали проблему несколько недель, анализировав счетчики производительности, на предмет утечек памяти, сбоев приложений, все пусто. Решили проблему, разобрав RAID и включив кэш зписи. SQLIO при этом показало увеличение в 10 раз скости записи, ~1900 IOSP и 3,5-3,7 mb/s а средняя длина очередь диска упала до 0,7. С тех проблема ушла в небытие, скорость входа\выхода пользователей в пиках  стала длиться секунды, а до этого на это уходило 1-2 минуты, и ни один сервер ни разу не завис, а зависали стабильно 1-2 сервера, раз в день. При том что каждый сервер обеспечивал работы от 130-200 пользователей (всего ферма обеспечивает больше тысячи пользователей)

    Я ни к чему не принуждаю, но могу сказать что это ВАРИАНТ.

    6 декабря 2015 г. 10:32
  • Да, это вариант. Только вот включать кэш в RAID-контроллере желательно при наличии батарейного резервирования (наверное, не зря его контроллер включать не позволял). А то так можно базу убить при внезапном пропадании питания.

    Другое дело, что у автора нагрузка совсем не такая, как у вас.


    Слава России!

    6 декабря 2015 г. 10:59
  • После включения кэша (контроллер позволил это сделать):

    sqlio v1.5.SG
    1 thread writing for 300 secs to file C:testfile.dat
            using 4KB random IOs
    using current size: 734 MB for file: C:testfile.dat
    initialization done
    CUMULATIVE DATA:
    throughput metrics:
    IOs/sec:   940.04
    MBs/sec:     3.67

    --------------------------------------------

    RAID10 из 4х SAS дисков.

    А если оставить включенным кэш. Сам сервер имеет ИБП. Всегда завершает работу мягко. Это не защитит данные? Или для контроллера нужен обязательно свое резервное питание, чтоб успевал выгрузить кэш?



    • Изменено ivldenis1 6 декабря 2015 г. 12:24
    6 декабря 2015 г. 12:09
  • Да, этого должно быть достаточно. Лишь бы питание не было отключено мгновенно.
    7 декабря 2015 г. 6:46