Кусочек закатившегося солнца .....

Вчера была типа презентация Оракла , дали подержать в руках новый процессор 

Проблемы и способы их решения

Вчера состоялся прикольный разговор - по-моему любопытный
Присутствует черный юмор , впечатлительным лучше не читать
Предыстория 
Я тут уже писал про сервера Т3-4  . Получили новую партию этих машинок и начались проблемы , очень серьезные , но не суть
На следующей неделе к нам приезжают менеджеры из Оракла - двигать Т4 .
Вчера - обсуждаем проблемы , их много и в общем полная задница .
Мой начальник -
"Вот Оракл приедет - пусть обьяснит , что за фигня творится , почему их поддержка - далее запикано "
Я - "Ничего они не обьяснят - это же продажники , и повлиять на суппорт и разработчиков они не могут"
"Так что делать , надо же что-то делать ? "
"Ну способы есть , но сейчас не применяются , к сожалению или счастью "
"Какие способы ?"
"Вариантов на самом деле много
Можно взять этих ораклистов в заложники и не отпускать пока не пофиксят все баги . Но это долго и муторно"
"Да ну .  А еще ?"
"Можно воспользоваться хорошо зарекомендовавшей себя практикой и отрубить  им  мизинец для начала"
Начальник мечтательно - 'Вот приезжают к нам представители Б...а - а у нас  в конференц-зале вязанки из пальцев развешаны '
"Отрезанные уши тоже хорошо "
К обмену мнениями подключается главный DBA -
"Мужики , представьте  - вокруг нашей стоянки шесты с черепами "
Мечты , мечты ....

Когда все хорошо

- то всегда найдется один мудак , который все испортит

И куча людей будет в бешеном напряге , поднимая упавшие сервера и все остальное
И все из-за тупого и безответственного электрика

Картинка нагрузки после аварии очень красочна

Продолжение истории про большой CPU

                Закон бутерброда по-серверному.
                 

Я тут писал о переходе на 11 версию Оракла и  неожиданном росте  CPU usage. Где-то недели через  две после перехода  Оракл выпустил очередной набор патчей , при прочтении которых наши ораклоиды сильно оживились  и обрадовались . Оказалось , что пожирание процессора было связано с одним из багов ( который патчами и закрывался).

Это классическое проявление эффекта серверного бутерброда - патчи появляются строго после того , как Вы УЖЕ перешли  на бажную версию
и столкнулись с этими багами .

Надо отметить также , что эта версия Оракла была выпущена достаточно давно.

Наши DBA - опытные и тертые ребята , проверили патчи и выждали еще пару недель на всякий случай - не появятся ли исправления на этот пакет .
После установки патчей на продуктовую базу уровень CPU вернулся к нормальному уровню .

PS . Этот блог засветили на хоботе , и тамошие эксперты тут же  заявили  -
"По этой линке стандартная ситуация после неоттестированной миграции, и версия тут не при чем. Планы и запросы нужно исправлять на этапе тестирования, а не после миграции."
То есть совершенно пальцем в небо .
Я еще раз убедился , что главная черта экспертов - уверенно вещать ни о чем

Сравнение обычных дисков  и  SSD 

Результат  использования   SSD дисков в нагруженных  базах  весьма положителен .Уменьшается  время выполнения дисковых операций ,снимается нагрузка с  обычных дисков
При примерной одинаковой  нагрузке около  1500-2500 IOPS  разница в  svc_time  - в  разы
График svc_time для SSD 

Для  обычных дисков svc_time т относительно неплох , но гораздо больше

Само собой , погоня за низкими svc_time  важны  в основном для  OLTP 

Разные версии и разный подход

Не так давно перевели базу на 11 версию Оракла.
Совершенно неожиданно резко выросло CPU usage  - на картинке хорошо видно что почти вдвое.
В общем - большая проблема .
DBA  перепробовали кучу вариантов , индексы-настройки , какие-то запросы переделали .
В результате потребление процессора снизилось до терпимого  .
Тем временем я решил стороной узнать  как дела с переходом на 11 Оракл обстояли в других местах .
Задал вопрос -
-было ли такое ?
-- да вроде было
-а как победили ?
--да купили пару М9000 и все стало нормально

Почувствуйте разницу :-)

Про производительность , ввод-вывод и wsvc_t

По роду службы занимаюсь  производительностью нагруженных  серверов баз данных
Нагруженные , в моем понимании  -  более  3  тысяч  IOPS , сейчас говорим про ввод-вывод . Тема обширная и даже необьятная , хочу обратить внимание интересующихся на параметр wsvc_t  в iostat .
Этот параметр относится скорее  к серверу , чем  дисковому storage
Определяет время пребывания запроса IO  в очереди
В нормальном режиме - значение 0
При сильной нагрузке на дисковую подсистему  может  расти
Однако , бывают случаи когда дисковая подсистема работает вполне нормально , аsvc_t  невелико , а wsvc_t растет
Обычно это означает некие проблемы на хосте(сервере)  , возможно связанные с работой драйверов HBA
Одной из таких проблем пришлось заниматься , решение нашлось простое и тупое  - просто надо увеличить число путей к портам дискового массива .

Вот пример статистики

Снова сравниваем T3-4 vs 5440

На этот раз сравниваются более нагруженные сервера баз данных
Напомню , что сравниваем
T3-4      1649 MHz  SPARC-T3
T5440   1414 MHz  SUNW,UltraSPARC-T2+

Вчерашняя загрузка на Т3-4  -  выше
Аналогичная  нагрузка на базу месяц назад на 5440

Хорошо видно , что нагрузка на Т3-4  меньше в разы
И совсем не совпадает со степенью увеличения частоты CPU  по сравнению с 5440

Вывод  - как ни странно , процессор Т3  действительно  намного лучше чем  Т2  !  :-) 

Про совпадения  , или разные снаряды в одну воронку



Пару дней назад апгрейдили FOS на Brocade
Процесс с одной стороны несложный , с другой - продуктовая платформа со всеми вытекающими .
Итак , все идет хорошо , прошли на одном 4900 два апдейта , заканчиваем второй 4900 .
Тут бах - на одном из серверов ругань в /var/adm/messages потоком
Проблема с одной из дисковых полок - ошибки на одном из lun-ов . Быстро смотрю порты , WWWN-ы, проверяю зоны - все на месте  , ничерта не понятно .
Тем более что полка к этому 4900 напрямую не подключена , но подсоединен сервер .
Выясняется -  через 3 минуты после FOS upgrage в полке вылетел один диск и потянул за собой весь кирпич ! 
Просто совпадение .....
Далее не так интересно , благодаря Zpool обошлось без потерь .

Второй снаряд

Тока что в серверной лазили под полом - искали оптику для VSP
нашли , перетянули куда надо , подвели прямо под шкаф
внезапно чувствуем запах чего-то горящего - такой густой и тяжелый
у меня душа натурально в пятки ушла 

Решил что где-то силовой кабель дернули .
Оказалось это незамеченные мной кондиционерщики что-то варят 

:-)

T2 vs T3

Наконец поступили новые серверы Т34 ( в просторечии "танки") 
Пока в работе один
Параметры следющие
  1649 MHz  SPARC-T3 , 256Gb memory ,512 thread
Сравниваем с Т5440  1164 MHz  SUNW,UltraSPARC-T2+  128Gb  128 thread

На 5440  -

  После переезда на Т34

Разница в скорости процессора налицо

Hardware на пенсии

"— Узнаешь ли ты этот славный корабль, Розенбум? Помнишь как славно палили на нем пушки, когда я ступал на его палубу?"  (с) Путешествие Нильса с дикими гусями




Довольно часто брендовые сервера  проживают долгую ( по сравнению с обычными десктопами) жизнь , меняя и иногда переживая своих хозяев .
Вот один из достойных представителей сановских серверов - SF890

Лет пять назад сервер был привезен одним замечательным системным интегратором ( на букву "C" :-) )  и поставлен в Call-center
Затем что-то пошло не так , и через год он оказался у меня в серверной и стоял выключенным .
Как раз тогда пришел новый сотрудник , и я отдал 890 ему для обучения - ну там поставить солярку , подключить полку через фабрику и т.д
Сервер замечательно справился с своей ролью , и пережил еще одного новичка .
Само собой места в стойке для него не нашлось , и его поставили 'на время' у стенки 
В не помню уже какой-то момент ораклистам что-то захотелось проверить , и они попросили этот сервер для экспериментов .
Потом прошло еще много времени , и сервер понадобился опять нам
Однако оказалось , что там крутится какая-то очень нужная база , которую никак нельзя выключать .
И прозвучал очень интересный термин - "полупродукт " :-)
Сейчас на этом сервере примерно такая картина -
bash-3.00$ hostname
v890test
-bash-3.00$ ps -aef | grep pmon | wc -l
       5

890 в общем повезло , судьба другого 880 сложилось печальнее

Когда-то это был главный биллинговый сервер , успешно державший первые сотни тысяч абонентов .
После замены на 6800 ( и т.д)  долго служил тестовым , пока у него не вышел из строя backplain .
Сейчас служит столиком для инструментов

Andy blogs

Привет

Собираюсь делиться тут любопытными и занимательными историями из около-ИТ сферы