Бег по граблям , или новый софт

Дерьмовая ситуация  с  современным софтописанием давно уже стала  общим местом , но в последнее время эта ситуация приобрела откровенно безумно-маразматический оттенок .
Ладно , я понимаю , что новый релиз  NB  сопровождается набором патчей размером в 2 Gb
Я еще могу предположить как происходят реинкарнация ошибок пятилетней давности  в драйверах Qlogic-a
Но вчерашняя ситуация - это уже загранью добра и зла .

Кратко сюжет  - продуктовая база стала сильно подтормаживать временами - вплоть до залипания консоли . Сотрудник (Зоркий сокол ) быстро нашел  источник проблем - см. картинку . 
Новая версия ораклового  агента EMGrid  жрет больше процессора , чем база , которую он должен мониторить . Охренеть .

ЗЫ.   Попытки штатного конфигурированя агента вчера успеха не дали .

ZFS vs VxFS - part 2

В пятницу не успел закончить пред. заметку  - пришлось срочно убегать .
Итак , ситуация была весьма скверная , основной причиной этого являлась чрезмерная склонность ZFS  кэшировать данные .  На слабых  'дисках'  это проявляется очень хорошо .
После некоторых раздумий было решено переразбить рейд-группы и поменять файловую систему .
Понятно , что для этого понадобилось  перенести куда-то лежащие там данные и времени это заняло немало .
Переделка рейдов
Из  двух  групп  по 11 дисков   6 рейда было сделано  4 группы пятого рейда .
Каждая группа  приводилась на хост , как и ранее ,  одним луном .  
Файловая система .
Было решено перейти за хорошо знакомую  старую добрую VxFS , вот результат

"Почувствуйте разницу"(c)

Понятно , что это не совсем чистое сравнение файловых систем , но подчеркну следующие моменты

1. Число и сами диски  остались без изменений
2. Данные  после обратного перемещения  прежние
3. Характер доступа к данным также не поменялся


В целом замечено , что VxFS  более равномерно осуществляет запись  , иногда даже   уменьшая производительность по IOPS . В результате диски  не "заклинивает"  на бесконечных 100%  device busy

ZFS против VxFS - сравнение

Пару лет назад  получили  большую  полку AMS2500 , SATA 2T disk
Ее прицепили к серверу DWH , на некоторое время вечная проблема нехватки места была решена . Для получения наибольшей отдачи по месту  для DWH сделали пару 6  raid group  9+2 . Каждая группа отдавалась на хост как один Lun , сверху решили положить ZFS как продвинутую и современную файловую систему .
Сначала , как всегда , все хорошо работало . Затем народ стал жаловаться , вполне обычно - "все тормозит , запросы медленно выполняются"
Анализ показал , что несмотря на клятвенные заверения DBA , что данные на полке ТОЛЬКО для чтения  , на нее  идет запись . Причем немалая .

В результате времена выполнения становились временами просто астрономическими . Busy на дисках - 100%
Более глубокое изучение показало ,  что ZFS кэширует данные на запись в памяти , а  затем пытается сбросить их на диск . Причем такое впечатление , что сбросить все сразу . Результат  , понятно , очень плохой

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

 

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

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

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

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

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

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

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

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