Занимаюсь извращением — собираю образ на базе wheezy.
А всё почему? Потому что клиенты посмотрят-посмотрят на новый продвинутый хостинг с nodejs и питонами да и пойдут на старый, ибо там php 5.2 всё ещё есть...
За что не люблю SSD, так это за непредсказуемость... Вчера работал, никаких проблем в SMART, сегодня — сдох до отсутствия на шине с точки зрения контроллера.
Вобщем, хорошая штука — RAID...
В локальной болталке от техподдержки:
"""
Сейчас с клиентом разговаривал:
Я:
— К сожалению, переадрессации на Mail.ru у нас нет.
Клиент:
— Плохо, уйду я от Вас
Я:
— Вы можете перенести весь Ваш почтовый домен на Mail.ru
Клиент (Цитата):
"- нет, спасибо я не настолько говноед"
"""
Один из наших днс-серверов находится в FirstVDS. Да, виртуалка, но для ns с номером 4 — это пока было достаточно.
Понадобилось повысить тариф, так как на текущем перестал справляться — выяснилось, что смена тарифа займёт до 2-х часов даунтайма вдс!
Вот как так можно, а?
У нас — в онлайне, в крайнем случае с перезагрузкой...
Они там что, руками в биос хоста лазят с полной перезаливкой оси?
За эту неделю 5 человек не пошли на новый хостинг потому, что им надо php с версией < 5.3
Возглас перед тормозящим интерфейсом графаны:
"""
Графаааняяя!
"""
Из рубрики "Эксперименты". На тестовом сервере с 300 виртуалок иногда возникали всплески LA с ~0.5 до 10, без всякой периодичности, просто на графике такая неравномерная гребёнка.
Как выяснилось, виноват шибкоумный openvswitch. На рабочих серверах больше нескольких десятков виртуалок никогда не было, так что там величина всплесков не превышает обычных флуктуаций при работе, но тем не менее...
На тестовом сервере с кучей ничего не делающих виртуалок наблюдаем всплески LA с 0.5 до 10-12.
Ни процессор, ни диски, ни сеть при этом не грузятся, консоль отвечает как обычно.
Пока подозрения — на локи в ядре, конкретно — в модуле kvm. Впрочем, пока ещё не тестили в рабочем режиме, так что хз, имеет ли смысл бороться с этим.
Тестировали тот сервер с кучей виртуалок на предмет "когда ж эта сволочь сдохнет" в смысле поднятия LA и работоспособности сайтов в тех виртуалках, куда поток запросов не летит.
Пока добились только упирания в сетевой интерфейс. Ладно, к тому, что не всякий инструмент тестирования работает так, как ожидалось, я привык. А вот к тому, что простой сервер, где никто нихрена не тюнил для производительности таки выдерживает тестирование с первого раза — пока ещё нет и это таки вызов, так как надо сделать так, чтоб хотя бы LA поднялся до уровня 2 на каждое ядро, а не как сейчас 0.5
Потестили виртуалки с KSM на хосте. Текущие результаты:
1) втиснули 300 виртуалок с жумлой по 2Гб памяти на хост с 96Гб памяти. После устаканивания — занято 53%. Устаканивание заняло порядка часа с 98% при последовательном запуске виртуалок по 5 штук каждые 10 секунд порциями по 100 штук с интервалом в 15 минут между порциями.
2) после того, как дали нагрузку на десяток виртуалок (apache bench) объём памяти резко сожрался до 62% и пока там и держится.
Выводы:
а) KSM работает и весьма неплохо
б) жрёт процессор не так уж и сильно
в) неэффективен, если виртуалки — клиентские, а не свои (в своих можно поддерживать идентичный набор софта и т.п.)
На тестовом сервере тормозит top, примерно секунда время реакции на пробел. И это ещё не все контейнеры подняли :-)
На тестовом сервере хостинга:
"""
h999:~# ps auxfw | wc -l
10335
"""
Крупный клиент прогнозирует повышение нагрузки на их сервер: к текущей ~50 запросов в секунду итого вместе со статикой добавится до 200rps на единственную страницу в пике.
Цитирую:
"""
У нас немного опыта в высоконагруженных системах, и сервис ЛК не писался для подобной нагрузки. Мы подкрутили, основные сервисы на которые ляжет нагрузка. А так же попросили увеличить количество ядер на сервере. С 4 до 8 ядер.
"""
Картина маслом: php5, виртуалка, нагрузка.
Подозреваю, что в текущей схеме они таки поздно спохватились — к 15 декабря вряд ли получится что-либо существенное сделать.
При тестировании на падение новой версии хостинга упёрлись в дефолтный kernel.pty.max, чего никто не ожидал
Какой-то странный товарищ хочет поставить TensorFlow на хостинг (не вдс!)
/me размышляет, 400+МБ базы sqlite — это уже повод порекомендовать переезжать на мускль или хрен с ним?
Пытаюсь сделать график topN по пикам трафика, данные по которому сохранены в clickhouse нарастающим итогом с периодическим переполнением.
В результате полный запрос состоит из 9 вложенных SELECT'ов и работает 140 секунд с данными за сутки. По-моему, надо как-то по-другому получать данные скорости из нарастающего итога трафика на адрес, чем runningDifference и последующая агрегация...
Про клиента и его 800+ адресов в cc — говорит, что это его клиенты, что по одному письму они отправлять не могут. На резонное предложение автоматизировать процесс он сказал, что они пользовались почтой Руцентра и там претензий к ним не было.
Ну чо, пусть и дальше пользуется почтой руцентра, тогда нам из-за него не придётся выколупывать сервер из спам-листов.
Нашелся клиент, который в CC: поставли 800+ получателей.
У нас ограничение в 40.
Причём, вроде как даже не спам, просто такая странная рассылка.