А что еще можно сделать на новостном движке ? сайт обладминистрации на DLE никто делать не будет.
Общее мнение о неоптимальных запросах в DLE возникло именно так, как я описал.
Это сёрч, тут это нормально. Никто из людей эти сайты не читает . По крайней мере не будет возмущаться если свой комментарий не увидит из-за кеширования.
в основном тупят запросы на поиск, вывод похожих новостей, поиск по тегам.
И, по-моему, самая большая проблема, которую не решить настройками, по крайней мере в dle 8.5 внутри было очень много запросов с calc_found_rows() - это просто вырвиглазный ужас. Так никто не пишет.
Суть говносайтостроительства в работе на массу. Чем больше говноновостей закуплено на говнобирже в виде готовых говнобаз или спарсено, тем больше говнотрафика притянет говносайт. Так что новостей обычно очень много. И тут sql-запросы закономерно становятся говнозапросами.
Высказавшиеся люди тоже ведь знают о чем говорят :)
Andreyka, найдутся и другие частные случаи когда mysql лучше бай дизайн. и что?
там другой дизайн, который противоречит текущим целям и другим преимуществам mysql, а именно совмещение в одном сервере разных storage engine-ов. Такого понятия как write ahead log не существует в mysql. Поэтому прежде чем записать и реплицировать результат запроса запрос нужно полностью исполнить.И кроме того, люди то все равно живут с mysql. Если погуглить есть "ускорители" этой самой репликации. Иногда приложение можно изменить так, что сложнейший запрос на мастере не будет уходить на слейв, но будет заменен простым запросом на обновление, который реплицируется легко и приятно.
Mysql не плохой, он другой. Выбирайте себе инструмент исходя из понимания принципов его работы и не будет никакой досады. Наивно ожидать, что для работы с данными нужно только лишь в общих чертах знать SQL. Нужно еще понимать как он работает. И это приходится делать работая с любым традиционным sql-сервером.
Сама популярность этих ваших редисов возникла потому, что о работе запроса к nosql-серверу программисту ничего понимать не нужно. Сервер слишком простой, просто делает свою работу.
Andreyka, можно использовать полусинхронную репликацию. данные не потеряются
могу еще парочку способов ускорения репликации припомнить. да только надо ли?
репликация и быстрая работа - противоположные цели.
Тут вон mysql обещает сделать memcached-подобный интерфейс. Может через пару лет все начнут понимать, что это не mysql тормозной, а программисты в SQL не разбираются.
Dimanych, трафик не захватил - сам себе злобный буратин. Теперь остается теоретизировать на пустом месте. В следующий раз используй tcpdump -w, скачивай файл и выкладывай - будет предметный разговор.
согласно этой картинке LAST_ACK это самое последнее состояние ожидания пакета от клиента ( ждем "recv ACK" как там подписано на стрелочке уходящей в CLOSED ). Так что
1. бот либо умышленно "забыл" про соединение,
2. либо твой сервер не получает финальное подтверждение от бота, поскольку бот забанен на уровне пакетного фильтра.
Ресурсов на соединение в LAST_ACK не так уж много расходуется. Второе мне кажется более вероятным.
Eсли понизить net.ipv4.tcp_fin_timeout, то таких состояний будет меньше. Но так ли важно сохранить их маленькими при небольших атаках? Были ли в dmesg ошибки "out of socket memory" ?
Помню случаи когда вроде бы верная "оптимизация стека для ddos" выливалась в страннейшие проблемы при нормальной работе сервера. сброс к настройкам по умолчанию все исправил. Я понимаю, что возможно было разобраться что именно от чего зависит, но мне это нерентабельно.
если баннер делал не только дизайнер но и программист, он вам расскажет как должен оформлять html-код партнер, чтобы внутрь флеш-клипа передавался код партнера. В любом случае потребуется доработать баннер, так что вы как непрограммист ничего не сделаете.
Dimanych, ну как же не прошли все стадии подключения?
если nginx не хватало обработчиков, значит соединение полностью установлено и ngnix должен сделать об этом запись, но уже после завершения этого соединения. Видимо, вы nginx останавливали (убивали) тем самым препятствуя записи в логи.
может у вас запись логов так настроена чтобы не писать их или вы смотрите в логи от виртуального хоста, а не глобальные.
можно только до определенного запаса мощности. tarpit нехило потребляет ресурсы относительно drop.
