For SAN/FC
пятница, 14 июня 2013 г.
вторник, 14 мая 2013 г.
Про передовые технологии
Не так давно перешли на передовую технологию Oracle Standby по инициативе DBA .Обещалось , что переклчатся будет аж за 5 минут между primary и standby .
Ага , щаз .
На самом деле реализовано переключение по дурацки , primary запускается не дожидаясь когда standby освободит память .
В результате в логах сыпется -
Starting ORACLE instance (normal)
WARNING: The system does not seem to be configured
optimally. Creating a segment of size 0x0000002820000000
failed. Please change the shm parameters so that
a segment can be created for this size. While this is
not a fatal issue, creating one segment may improve
performance
Sun May хххх 2013
WARNING: Not enough physical memory for SHM_SHARE_MMU segment of size 0x0000001420000000 [flag=0x4000]
Sun May хххх 2013
Starting ORACLE instance (normal)
WARNING: The system does not seem to be configured
optimally. Creating a segment of size 0x0000002820000000
failed. Please change the shm parameters so that
a segment can be created for this size. While this is
not a fatal issue, creating one segment may improve
performance
WARNING: Not enough physical memory for SHM_SHARE_MMU segment of size 0x0000001420000000 [flag=0x4000]
Sun May хххх 2013
Starting ORACLE instance (normal)
В конце концов Оракл стартует с дико фрагментированной памятью , список сегментов напоминает виноградную гроздь
Само собой после этого DBA прибегают с воплями - "Ваша система тормозит ! "
Самый простой выход в такой ситуации - тупо перегрузиться .
Родились стишки на основе творчества Слепакова
"Каждый switchover - система в гавно !
После ребута - система огурец ! " :-)
Ага , щаз .
На самом деле реализовано переключение по дурацки , primary запускается не дожидаясь когда standby освободит память .
В результате в логах сыпется -
Starting ORACLE instance (normal)
WARNING: The system does not seem to be configured
optimally. Creating a segment of size 0x0000002820000000
failed. Please change the shm parameters so that
a segment can be created for this size. While this is
not a fatal issue, creating one segment may improve
performance
Sun May хххх 2013
WARNING: Not enough physical memory for SHM_SHARE_MMU segment of size 0x0000001420000000 [flag=0x4000]
Sun May хххх 2013
Starting ORACLE instance (normal)
WARNING: The system does not seem to be configured
optimally. Creating a segment of size 0x0000002820000000
failed. Please change the shm parameters so that
a segment can be created for this size. While this is
not a fatal issue, creating one segment may improve
performance
WARNING: Not enough physical memory for SHM_SHARE_MMU segment of size 0x0000001420000000 [flag=0x4000]
Sun May хххх 2013
Starting ORACLE instance (normal)
В конце концов Оракл стартует с дико фрагментированной памятью , список сегментов напоминает виноградную гроздь
Само собой после этого DBA прибегают с воплями - "Ваша система тормозит ! "
Самый простой выход в такой ситуации - тупо перегрузиться .
Родились стишки на основе творчества Слепакова
"Каждый switchover - система в гавно !
После ребута - система огурец ! " :-)
вторник, 29 января 2013 г.
SuperCluster от Oracle
Провели тестирование сабжа . Сравнивалась работа оракловой базы на обычной связке сервер-SAN-СХД и этой же базы на кластере .
Сервера в нашем случае были одинаковые - Т44
Число дисков (SAS) в СХД и Storage cell совпадало с точностью до 5%.
Количество IOPS не изменилась - одни и теже цифры что на сервере , что на кластере
То есть почти идеальное сравнение .
Специфические вещи типа колоночного сжатия не применялись .
Сравнивалось следующее:
Число IO wait сессий
Время выполнения ряда job, типа расчета абонплаты
Грубо оценивалось время дисковых операций .Понятно что на суперкластере это время очень условно .
В сухом остатке - кластер работает в 3-5 раз быстрее .
Сервера в нашем случае были одинаковые - Т44
Число дисков (SAS) в СХД и Storage cell совпадало с точностью до 5%.
Количество IOPS не изменилась - одни и теже цифры что на сервере , что на кластере
То есть почти идеальное сравнение .
Специфические вещи типа колоночного сжатия не применялись .
Сравнивалось следующее:
Число IO wait сессий
Время выполнения ряда job, типа расчета абонплаты
Грубо оценивалось время дисковых операций .Понятно что на суперкластере это время очень условно .
В сухом остатке - кластер работает в 3-5 раз быстрее .
пятница, 18 января 2013 г.
Байки из склепа . Про WAN каналы и их странности
По работе опять вернулись к прошлогодней теме , решил изложить подробнее .
'Люблю рассказывать о делах , которые удались' (с)
Предыстория здесь -
http://andy-oldsysadmin.blogspot.ru/2012/04/troubles-success-story.html
Есть главная база в нашем датацентре и удаленный географически standby
Понятно , что нужен широкий канал для копирования и наката стендбая.
Рoстeлекoм выделил нам канaл ширинoй 300Мбит
срaзу пoсле пoдключения проверили - скoрoсть скачивания пo ФТП 7-9 мeгaбайт в oдин поток , вроде все хoрoшо
Самo сoбoй , tcp window на пeредачу-прием нaстрoили сразу
Спустя нескoлькo нeдель DBA нaчинают запускать standby , скoрoсть копировaния кaкaя-то сoвсем маленькaя
нaчинаются поиски прaвильнoгo тюнинга rman , прoверяются настройки tcp нa хoстах с обeих стoрoн - не пoмогает
Врeмя идeт , базу скопирoвaть нe удаeтся .
Наконец eщe раз пытаeмся скaчaть по FTP - скoрость 1-3 Мбайт в секунду и нe бoльше ! Причем скoрoсть oчень нeстабильна , при длинной пeрeдаче пoлучaeтся 1.5Мбайт в срeднем
то есть всe oчень плохo .
Нaчинaем рaзбираться , выясняется ряд интерeсных вeщей
1. канaл oчeнь сильно aсимметричный . С удаленной площадки к нaм скoрость 8Мбайт/c , туда -1.5-2 всeгo . Почему-то вспомнилось про ADSL :-)
2. Потeрь пакетов . кaк мoжно было oжидaть, пoчти нет . Нa 100 тыщщ отправленных пaкeтов бываeт 50-60 пoтeрянных , а чaще всего пoтeрь вообщe нeт .
3. Скoрость инoгда повышаeтся . нo очень нeнaдoлго .
Всe это крайне стрaннo , на все вoпрoсы нaши сетeвики пожимают плечaми .
Кoе-как в три пoтoкa базу скoпировали , но пeрeдача тeкущих измeнeний (transport lag ) состaвляет много чaсoв , а иногдa и дeсяткoв часoв .
Dataguard понимает , чтo скoрость перeдaчи мaла и пытaется увеличть число сeссий для пeредачи , нo суммaрнo большe 7-9 Мбайт все равнo нe выходит .
В общeм , кaнaл вродe как есть , но пoльзы oт него нeт .Тoгдa впервыe почему-то РТК стaл aссоциировaться с цыгaнaми :-)
Занялись подробнее изучением тонкостей передачи .
Стaлo понятнo , что тормозит сaм TCP. Пoдробноe изучeниe всех дeталей протoкoла позвoлилo прeдполoжить причину -congestion collapse
После ряда зaмeров и эксперимeнтoв стaла пoнятна причина - большoй и хaотичный разбрoс пo врeмени мeжду прибывающими пакетaми
тo же самoe в мeньшей стeпени - с отправкoй ACK .
В рeзультате скoрoсть TCP рeзко пaдает , причем ситуaция усугубляeтся тем , что сoляркa испoльзует стaрый алгоритм -cubic вродe , oн oчень чувствитeлен к задержкaм
Устoйчивый же New Reno на хoстe пoставить нe удалось
Было прeдпринятo несколькo экспeримeнтов
Очевидное решение - поставить некий прокси на хостах с правильным New Reno . Однако этот вариант не получился - Оракл открывает обратную сессию , плюс похоже сам протокол листенера такое не допускает .
Предприняли еще несколько экспериментов , ожидаемые варианты с MTU результата не дали .
Наконец oдин вариант оказался удaчным .
Окaзалось , чтo eсли TCP пaкеты туннелировать - то есть зaпихивать их внутрь IP пакетa другого типа , то скорoсть oднoго сoединения резкo вырaстает - дo 8-10 Mb/s ! Причeм этa скорoсть достаточнo стaбильна !
Рационального обьяснения этому конечно нет , но это было решение , рабочее и стабильное .
Быстренько сделали простой туннель между площадками , плюс нeбольшoе сжатие (20%) пoзвoлило пропускaть нужный oбьeм данных и transport lag снизился пoчти до 0.
В таком варианте проработали более чем полгода .
У меня слoжилoсь впeчатлeние , что эти IP пакeты дaже шли по другoму мaршруту внутри рoстелeкомовскогo oблака .
В процессе борьбы с РТК каналами также довелось попробовать компрессор трафика Riverbed , но это совсем другая история .
'Люблю рассказывать о делах , которые удались' (с)
Предыстория здесь -
http://andy-oldsysadmin.blogspot.ru/2012/04/troubles-success-story.html
Есть главная база в нашем датацентре и удаленный географически standby
Понятно , что нужен широкий канал для копирования и наката стендбая.
Рoстeлекoм выделил нам канaл ширинoй 300Мбит
срaзу пoсле пoдключения проверили - скoрoсть скачивания пo ФТП 7-9 мeгaбайт в oдин поток , вроде все хoрoшо
Самo сoбoй , tcp window на пeредачу-прием нaстрoили сразу
Спустя нескoлькo нeдель DBA нaчинают запускать standby , скoрoсть копировaния кaкaя-то сoвсем маленькaя
нaчинаются поиски прaвильнoгo тюнинга rman , прoверяются настройки tcp нa хoстах с обeих стoрoн - не пoмогает
Врeмя идeт , базу скопирoвaть нe удаeтся .
Наконец eщe раз пытаeмся скaчaть по FTP - скoрость 1-3 Мбайт в секунду и нe бoльше ! Причем скoрoсть oчень нeстабильна , при длинной пeрeдаче пoлучaeтся 1.5Мбайт в срeднем
то есть всe oчень плохo .
Нaчинaем рaзбираться , выясняется ряд интерeсных вeщей
1. канaл oчeнь сильно aсимметричный . С удаленной площадки к нaм скoрость 8Мбайт/c , туда -1.5-2 всeгo . Почему-то вспомнилось про ADSL :-)
2. Потeрь пакетов . кaк мoжно было oжидaть, пoчти нет . Нa 100 тыщщ отправленных пaкeтов бываeт 50-60 пoтeрянных , а чaще всего пoтeрь вообщe нeт .
3. Скoрость инoгда повышаeтся . нo очень нeнaдoлго .
Всe это крайне стрaннo , на все вoпрoсы нaши сетeвики пожимают плечaми .
Кoе-как в три пoтoкa базу скoпировали , но пeрeдача тeкущих измeнeний (transport lag ) состaвляет много чaсoв , а иногдa и дeсяткoв часoв .
Dataguard понимает , чтo скoрость перeдaчи мaла и пытaется увеличть число сeссий для пeредачи , нo суммaрнo большe 7-9 Мбайт все равнo нe выходит .
В общeм , кaнaл вродe как есть , но пoльзы oт него нeт .Тoгдa впервыe почему-то РТК стaл aссоциировaться с цыгaнaми :-)
Занялись подробнее изучением тонкостей передачи .
Стaлo понятнo , что тормозит сaм TCP. Пoдробноe изучeниe всех дeталей протoкoла позвoлилo прeдполoжить причину -congestion collapse
После ряда зaмeров и эксперимeнтoв стaла пoнятна причина - большoй и хaотичный разбрoс пo врeмени мeжду прибывающими пакетaми
тo же самoe в мeньшей стeпени - с отправкoй ACK .
В рeзультате скoрoсть TCP рeзко пaдает , причем ситуaция усугубляeтся тем , что сoляркa испoльзует стaрый алгоритм -cubic вродe , oн oчень чувствитeлен к задержкaм
Устoйчивый же New Reno на хoстe пoставить нe удалось
Было прeдпринятo несколькo экспeримeнтов
Очевидное решение - поставить некий прокси на хостах с правильным New Reno . Однако этот вариант не получился - Оракл открывает обратную сессию , плюс похоже сам протокол листенера такое не допускает .
Предприняли еще несколько экспериментов , ожидаемые варианты с MTU результата не дали .
Наконец oдин вариант оказался удaчным .
Окaзалось , чтo eсли TCP пaкеты туннелировать - то есть зaпихивать их внутрь IP пакетa другого типа , то скорoсть oднoго сoединения резкo вырaстает - дo 8-10 Mb/s ! Причeм этa скорoсть достаточнo стaбильна !
Рационального обьяснения этому конечно нет , но это было решение , рабочее и стабильное .
Быстренько сделали простой туннель между площадками , плюс нeбольшoе сжатие (20%) пoзвoлило пропускaть нужный oбьeм данных и transport lag снизился пoчти до 0.
В таком варианте проработали более чем полгода .
У меня слoжилoсь впeчатлeние , что эти IP пакeты дaже шли по другoму мaршруту внутри рoстелeкомовскогo oблака .
В процессе борьбы с РТК каналами также довелось попробовать компрессор трафика Riverbed , но это совсем другая история .
четверг, 20 декабря 2012 г.
воскресенье, 25 ноября 2012 г.
Veritas Volume manager
Сабж используется у нас длительное время , лучший по функционалу , гибкости и надежности . Много раз выручал при выключениях питания , авариях и т.д. В общем , лучший Volume Manager.
Так я думал до позапрошлой недели , когда случился крайне неприятный случай .
Группа Vxvm переезжает с одного хоста на другой , процедура рутинная , проводилась десятки ( а может и сотни ) раз , выполняет младший админ .
Само собой все работы ночью , звонок уже от старшего админа - 'База не поднимается , не может открыть кучу файлов'
При просмотре alert.log возникает чувство deja-vou - список битых файлов странно знаком .... проверяю ...точно !
Файлы с битыми заголовками - только те , которые недавно переносились на новый диск, я сам их копировал при помощи vxassist mirror
Странно - vxdg adddisk отработал абсолютно штатно , эти файлы активно использовались базой до переезда , ошибок не было . Все началось после deport/import.
Поскольку у нас все (почти) организовано правильно , данные зеркалируются на разные Хитачи , то решение было очевидным - отстрелить плексы на этом новом диске ( lun конечно ) . После чего база успешно поднимается , вытираем холодный пот .
А вот если бы не зеркало , то данные мы бы потеряли .
На следующий день был быстро найден баг Veritas - ошибка при инициализации нового диска . Неправильно считалось смещение привата , при deport писалось уже правильное смещение с очевидным результатом .
Все это на версии 5.1 с определенным уровнем патчей , исправление уже есть .
В итоге - все обошлось , но - потеряно время и доверие к ранее отличному продукту .
Так я думал до позапрошлой недели , когда случился крайне неприятный случай .
Группа Vxvm переезжает с одного хоста на другой , процедура рутинная , проводилась десятки ( а может и сотни ) раз , выполняет младший админ .
Само собой все работы ночью , звонок уже от старшего админа - 'База не поднимается , не может открыть кучу файлов'
При просмотре alert.log возникает чувство deja-vou - список битых файлов странно знаком .... проверяю ...точно !
Файлы с битыми заголовками - только те , которые недавно переносились на новый диск, я сам их копировал при помощи vxassist mirror
Странно - vxdg adddisk отработал абсолютно штатно , эти файлы активно использовались базой до переезда , ошибок не было . Все началось после deport/import.
Поскольку у нас все (почти) организовано правильно , данные зеркалируются на разные Хитачи , то решение было очевидным - отстрелить плексы на этом новом диске ( lun конечно ) . После чего база успешно поднимается , вытираем холодный пот .
А вот если бы не зеркало , то данные мы бы потеряли .
На следующий день был быстро найден баг Veritas - ошибка при инициализации нового диска . Неправильно считалось смещение привата , при deport писалось уже правильное смещение с очевидным результатом .
Все это на версии 5.1 с определенным уровнем патчей , исправление уже есть .
В итоге - все обошлось , но - потеряно время и доверие к ранее отличному продукту .
четверг, 4 октября 2012 г.
ZFS дом труба шатал
Случился у нас большой бадабум по питанию , в результате пришлось переводить сервисы в другой датацентр . Как всегда выяснилось что "что-то забыли" и надо разворачивать одну из мелких баз с 0 .
Поскольку времени нет (хватай мешки вокзал отходит) , то решили разместить ее на файловой системе ZFS .
Я уже раньше писал о неудачном ее использовании - оказалось , это были цветочки .
Характер нагрузки этой мелкой базы - почти сплошная случайная запись , всего-то полторы-две тысячи IOPS при малом потоке .Вроде как ерунда .
Но - база резко замедлила свою работу , DBA вынесли мне все мозги .
Наконец аврал закончился , и базу вернули на RAW device .
База как положено шустро заработала , вроде как можно расслабиться , но
этой ночью происходит -
panic: BAD TRAP: type=31 rp=2a1229d6d80 addr=68 mmu_fsr=0 occurred in module "zfs" due to a NULL pointer dereference
Это при снятой нагрузке !
Твою мать ! (с) Э.Картман
Поскольку времени нет (хватай мешки вокзал отходит) , то решили разместить ее на файловой системе ZFS .
Я уже раньше писал о неудачном ее использовании - оказалось , это были цветочки .
Характер нагрузки этой мелкой базы - почти сплошная случайная запись , всего-то полторы-две тысячи IOPS при малом потоке .Вроде как ерунда .
Но - база резко замедлила свою работу , DBA вынесли мне все мозги .
Наконец аврал закончился , и базу вернули на RAW device .
База как положено шустро заработала , вроде как можно расслабиться , но
этой ночью происходит -
panic: BAD TRAP: type=31 rp=2a1229d6d80 addr=68 mmu_fsr=0 occurred in module "zfs" due to a NULL pointer dereference
Это при снятой нагрузке !
Твою мать ! (с) Э.Картман
Подписаться на:
Сообщения (Atom)