- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Да какая разница какой объем? Она в основном по колву соединений крашится.
Тут надо изучать. Или убирать постоянное соединение, или увеличивать лимиты, или действительно усиливать базу.
Вариантов усиления много разных.
Изначально конечно надо изучить индексы. Убрать/добавить. Может поменять СУБД (да, я так понимаю кроме комьюнити-версии на постгри, официальной так и не написали, но как минимум есть Машка, она чуть пошустрее, да и просто обновление версии иногда помогает). Ну и конечно надо смотреть во что мы при этом упираемся. Если действительно не просто лимиты отсекают базу при умеренной нагрузке на базу, а реально железу плохо, то надо смотреть где именно. Память? IO? Проц? Апгрейд сервера? (не обязательно на более мощный тариф, иногда можно просто чуть памяти докинуть или сменить родительскую ноду и т.п. Если знаешь где проблема, то уже будешь пилить куда надо). Докинуть еще ноду, сделав репликацию? Вариантов много...
Версия ДДоСа в принципе не состоятельная. ДДоС от авторизованных? Анриал. Иначе бы захлебнулись в спаме, его гораздо сложнее вычищать чем просто ддос.
ДДоС от неавторизованных? Так тут полно надежных решений. И свой кеш спасет, и клудфларе вполне приличен.... Форма авторизации? Даже банальная рекапча снимет нагрузку почти в ноль. Да и полно решений на этот случай. Форма поиска у неавторизованных? Выкинуть к черту.
Итого резюмирую:
1 - это не может быть ДДоС
2 - это не нормально. Тем более находясь в такой тематике
3 - падает от лимитов колва соединений, и мне и многим интересно оправданы ли они, или просто дефолт остался. Вдруг одна циферка всё спасет?) Ну раз уж за размеры базы спрашивают, то могу и я спросить?)
4 - всё решается).
Да какая разница какой объем?
Падает по ночам примерно в одно время - в большинстве случаев это с бакапами связано. Может спецом отключают. Большой объем может долго бакапится, хотя конечно даже для 40гб несколько часов это лол.
2 - это не нормально. Тем более находясь в такой тематике
Пока конкурентов нет, кому это надо?:) Появятся конкуренты - за пару дней всё поправят.
3 - падает от лимитов колва соединений, и мне и многим интересно оправданы ли они, или просто дефолт остался. Вдруг одна циферка всё спасет?) Ну раз уж за размеры базы спрашивают, то могу и я спросить?)
Размеры базы Gray на предыдущей странице писал.
А проблема с количеством соединений и нагрузкой на базу достаточно типична для вбуллетин на дефолтных настройках, мы поэтому про вложения и написали. В 80% проблема уходит с
а) Перекладыванием аттачментов (бинарных файлов) из базы в файлы. Т.к. бинарники из базы тянуть это не айс и по времени и по нагрузке и по тому факту что соединение висит.
б) Отдачей аттачментов не скриптом соединяющимся с базой и держащим соединение с базой пока файл не уйдет (т.е. не так ), а просто статикой (вообще не трогая базу или трогая ее только в момент проверки прав доступа, а потом отсоединяясь).
Вижу 2 варианта решения проблемы:
1) Инкрементальный бэкап
2) Репликация Master-Slave и делать бэкап на Slave
Падает по ночам примерно в одно время - в большинстве случаев это с бакапами связано.
Падает далеко не только по ночам, и не только в одно время.
Причем падение с формулировкой о лимитах колва соединений связанное с бекапом? Вы серьезно? Так и представляю себе Грея который каждый вечер заводит будильник на 3 часа ночи, чтобы лично зайти в конфиги уменьшить колво соединений разрешенное.
Пока конкурентов нет, кому это надо? Появятся конкуренты - за пару дней всё поправят.
Вы всерьез думает что конкурентов нет?)
Размеры базы Gray на предыдущей странице писал.
Меня интересуют лимиты на колво потоков а не объем базы. Объем базы интересен вам.
А проблема с количеством соединений и нагрузкой на базу достаточно типична для вбуллетин на дефолтных настройках, мы поэтому про вложения и написали. В 80% проблема уходит с
За дефолтные настройки и атачменты - согласен полностью.
Причем падение с формулировкой о лимитах колва соединений связанное с бекапом? Вы серьезно?
Да.
Так и представляю себе Грея который каждый вечер заводит будильник на 3 часа ночи, чтобы лично зайти в конфиги уменьшить колво соединений разрешенное.
Есть более реалистичные сценарии.
Наиболее частый: бакап создает нагрузку на сервер, запросы от клиентов обрабатываются не за 0.2, а за 0.4 секунды. Висящие в 2 раза дольше запросы естественным образом приводят к увеличению одновременно висящих соединений, они выходят за лимит - вуаля.
Вы всерьез думает что конкурентов нет?)
Какие-то конечно есть. Нет достаточно развитых и пересекающихся по ЦА, что бы им был реальный толк от падающего сёрча.
Весь день безуспешно пытался авторизоваться. Удалось это сделать только в мобильной версии форума.
Как только вижу ошибку на серче, сразу начинаю напиваться.
А если б не было ошибок - забывал бы.
Полезная фича, хватит ныть и бороться с ней.
Есть более реалистичные сценарии.
Наиболее частый: бакап создает нагрузку на сервер, запросы от клиентов обрабатываются не за 0.2, а за 0.4 секунды. Висящие в 2 раза дольше запросы естественным образом приводят к увеличению одновременно висящих соединений, они выходят за лимит - вуаля.
Забавно, но по нормальному бекап либо монопольно забирает базу (или как минимум блокировка записи), или висит себе в фоне без жуткого отжирания всего ресурса. Двукратное увеличение времени запроса? Ну разве что если HDD а не SSD. А единицы процентов, или даже 30% увеличения времени это не повод ронять сервер, т.е. поднять лимит и не морочить себе и всем голову.
Но ок, версия умеренно правдоподобна, так что не будем спорить а вернемся к тому что нифига он не в три часа ночи падает, а очень даже в часы пик, когда ни один пьяный не поставит бекапы.