После большого перерыва посмотрел  и пришел к выводу что  блог имеет явный отрицательный крен  -  сплошные troubles
Решил добавить success story 
Итак ,  некая продуктовая база  имеет удаленный стандбай , на который в горячем режиме накатываются изменения . В общем , совершенно стандартная схема , но "есть нюанс" (с) :-)
который заключается в том , что канал предоставляет местный провайдер  весьма паршивого качества  ( оба паршивые  -  и канал и пров )
Передача   данных  весьма сильно тормозит , что приводит к отставанию стандбайной базы от основной .
Разбирательства показали , что в канале часто возникают задержки между пакетами  , как итог  скорость передачи моментально падает . Пров невменяем , а другие в нашей деревне отсутствуют .
После некоторых экспериментов удалось таки наладить быструю передачу данных  на standby - картинка очень наглядна . По оси Y - отставание в секундах , до тюнинга  реально был лаг  15-18 тысяч  секунд .

 

Черная пятница

Все-таки в приметах что-то есть .
Сюжет
Внезапно растет цпу-шная нагрузка на сервере , до полного практически останова. Шелл еле живой , база само собой в глубокой заднице .
Все 256 потоков заняты  выполняющимися сессиями и трехтысяная очередь к этим же процам . Короче - полный мрак . Иллюстрация степени мрака - на картинке

Но - самое прикольное , что первый раз такое произошло в пятницу  13
второй раз сегодня - тоже пятница

Что-то в этом есть

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

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

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

Вчера состоялся прикольный разговор - по-моему любопытный
Присутствует черный юмор , впечатлительным лучше не читать
Предыстория 
Я тут уже писал про сервера Т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