Пользуюсь с первого релиза, в для проектов на TypeScript, Python, Go
Сразу, что понравилось — это быстрая работа с git, когда нужно проверить изменения и сделать коммит.
Вообще ограничивать запросы на API иногда оказывается полезно.
Достал тут как-то один пользователь.
Ломится, понимаешь, на API /Auth несколько раз в секунду с одним и тем же неправильным логин-паролем.
В принципе пофиг, просто логи читать мешает.
Вообще для пользования сервисом достаточно было /Auth один раз в 4 часа вызвать, так что поставили ограничение на 1 запрос в минуту.
Не таким, конечно, способом как в статье, а на nginx limit_req.
Так что бы вы думали, ни один пользователь не пожаловался, кроме своих же.
«Уберите ограничение, мы тут че-то это не кэшируем ...»
«А нам тут надо много и сразу...»
Ограничение конечно убрали, а тот пользователь с плохим паролем похоже намек понял и больше так не делает :)
Пару дней назад перевели часть серверов на Centos 7.0
Один из самописных сервисов на старом init-скрипте номально не стартовал по причине того, что systemd не мог найти pid-файл и висел ожидая когда он появится. Искал pid-файл он совсем не там, где он на самом деле был.
Оказалось, что кривой путь был где-то в комментарии скрипта, который systemd зачем-то еще и запомнил.
Т.е. после правки нужно еще запускать systemctl daemon-reload.
Тимо Бола в китае хорошо знают и любят за то, что он единственный, кто достаточно успешно в сравнении с другими европейцами противостоит местным китайским спортсменам.
Датацентр ведь не из соломы построен, чтобы падать во время «сильного урагана».
По идее там все должно быть задублировано и запередублировано. А тогда какой-то сорванной с крыши железякой расхреначило систему охлаждения и они все вырубили. Не надежный какой-то ДЦ.
Несмотря на то, что postgresql — действительно лучше mysql как сервер, иногда нужно тупо хранить какие-то данные просто в таблице без замашек на всякие крутые штуки, типа хранимых процедур, хитрых индексов, типов данных и т.п.
В нашем случае это как раз так — мы очень редко пишем в базу, чуть чаще читаем, а для всего остального используем масштабируемые key-value хранилища.
Еще бы было интересно узнать как осуществляется поддержка технологической платформы.
Например, «виртуальные коммутаторы» — это конечно круто, но по любому не без причуд.
Соответственно нужны сильные системные программисты у себя или их поддержка от разработчика платформы.
Для collectd кажется есть специальный кэш, который эту проблему решает и он не каждый пакет скидывает на диск. Да, есть риск потери пачки данных, но так это и решение не для атомной АС.
Согласен, но тут нигде речи не идет о том, что это все супер-мега надежно.
А на счет «графики нужны раз в полгода» — это не всегда так.
Например, у нас был случай — выкатили новую версию сервиса, через неделю по графикам увидели, что течет память. Тут же понятно когда началась утечка. Посмотрели по дате коммит, быстро нашли в чем косяк.
Даже если бы на час что-то выключали, то на надельном графике пробел был бы ну может в одну точку.
Например, у нас сервисы не только на python, но и на .NET. Не нужно никаких «читателей». Сервисы сами присылают данные.
Вообще pull-модель, когда кто-то ходит и опрашивает сервисы имеет явные недостатки (о которых я написал в самом начале) перед таким inline решением:
— приходится перенастраивать «читателя» при переносе сервисов или развертывании новых
— это более тяжеловесная модель и менее масштабируемая (см. обзор архитектуры)
@juise Александр, скажите пожалуйста в чем была причина перехода с Centos на Oracle Linux?
http://linus-torvalds.livejournal.com/616.html
https://geektimes.ru/post/124563/
Сразу, что понравилось — это быстрая работа с git, когда нужно проверить изменения и сделать коммит.
Достал тут как-то один пользователь.
Ломится, понимаешь, на API /Auth несколько раз в секунду с одним и тем же неправильным логин-паролем.
В принципе пофиг, просто логи читать мешает.
Вообще для пользования сервисом достаточно было /Auth один раз в 4 часа вызвать, так что поставили ограничение на 1 запрос в минуту.
Не таким, конечно, способом как в статье, а на nginx limit_req.
Так что бы вы думали, ни один пользователь не пожаловался, кроме своих же.
«Уберите ограничение, мы тут че-то это не кэшируем ...»
«А нам тут надо много и сразу...»
Ограничение конечно убрали, а тот пользователь с плохим паролем похоже намек понял и больше так не делает :)
Один из самописных сервисов на старом init-скрипте номально не стартовал по причине того, что systemd не мог найти pid-файл и висел ожидая когда он появится. Искал pid-файл он совсем не там, где он на самом деле был.
Оказалось, что кривой путь был где-то в комментарии скрипта, который systemd зачем-то еще и запомнил.
Т.е. после правки нужно еще запускать systemctl daemon-reload.
По идее там все должно быть задублировано и запередублировано. А тогда какой-то сорванной с крыши железякой расхреначило систему охлаждения и они все вырубили. Не надежный какой-то ДЦ.
Вот, например, так.
LINQ-2-SQL
В нашем случае это как раз так — мы очень редко пишем в базу, чуть чаще читаем, а для всего остального используем масштабируемые key-value хранилища.
Например, «виртуальные коммутаторы» — это конечно круто, но по любому не без причуд.
Соответственно нужны сильные системные программисты у себя или их поддержка от разработчика платформы.
А на счет «графики нужны раз в полгода» — это не всегда так.
Например, у нас был случай — выкатили новую версию сервиса, через неделю по графикам увидели, что течет память. Тут же понятно когда началась утечка. Посмотрели по дате коммит, быстро нашли в чем косяк.
Даже если бы на час что-то выключали, то на надельном графике пробел был бы ну может в одну точку.
Вообще pull-модель, когда кто-то ходит и опрашивает сервисы имеет явные недостатки (о которых я написал в самом начале) перед таким inline решением:
— приходится перенастраивать «читателя» при переносе сервисов или развертывании новых
— это более тяжеловесная модель и менее масштабируемая (см. обзор архитектуры)