Metal Messiah

Metal Messiah
Рейтинг
175
Регистрация
01.08.2010
Программистъ

про cgroups я просто не знаю, с учетом того что это VPS доступа может и не быть

nice можно попробовать, если решит проблему - хорошо. ок, тестирую, спасибо

Может надо сервер настроить или ресурсов ему больше или сайт настроить?

Может, но оптимизация имеет свой предел и лучше сделать так чтобы 1 ядро было занято одним процессом, а остальные ядра - всеми остальными процессами, тогда в случае любого ЧП тормозов не будет.

Ресурсов больше точно не надо, большую часть времени те что есть используются наполовину, но пока все работает не в полную мощность.

Andreyka, спасибо, но судя по команде

bsub -R "affinity[core:membind=localprefer]"./myapp

задается при запуске, так же как я сейчас делаю через taskset. Команда позволяет дать affinity при запуске или уже работающим процессам по pid, а apache в режиме prefork создает эти процессы сам...

iHead, отдельное спасибо, это вроде бы оно. Стояло

worker_processes 2;

добавил

worker_cpu_affinity 0001 0010;

буду смотреть.

Что касается mysql, нашел информацию о innodb_thread_concurrency, innodb_write_io_threads, innodb_read_io_threads но там ни слова о том как задать конкретные ядра, только рекоммендация давать конкуренцию 2*количество ядер, да и у меня myisam.

Больше про mysql и apache ничего не нашел.

Тут написано как повесить все процессы на 1е ядро при загрузке и не трогать остальные, видимо так и сделаю, только в моем случае не на первое а на все кроме первого, только не понимаю что за pid 1 и будет ли оно работать.

Еще есть вариант вклеить запуск через taskset в скрипты, лежащие в /etc/init.d/ но там не очевидно куда, буду копаться

Окончательно отказался от идеи прокси, php отправляет запрос на нужный сервер, подключение идет к местеру и одному из слейвов в порядке приоритета по мере необходимости (т.е. при первом запросе)

Тему можно считать закрытой, всем спасибо.

Вообщем, все будут привыкать к понятию Greenwich Mean Time, о чем напишу мелким шрифтом. Системное время не трогал, все решил установкой

date_default_timezone_set('UTC');

в config.php, который инклюдится во все остальные скрипты сайта.

Ну тогда уже лучше форумный вариант - "столько-то минут назад"

Есть еще 1 проблема: при чтении 2 разными веб серверами из одной базы MySQL выводится на сайте разное время одного и того же события.

На 1 сервере БД и сайт, в системе GMT+0, выводит 08.09.14 12:03

На 2 сервере сайт, время EEST, выводит 08.09.14 16:03.

При подключении к MySQL даю запрос

SET time_zone = '+02:00'

или ставил 3 или 4 часа, в результате ничего не меняется, время все то же, везде хранится как unix timestamp (результат time() из php) int(4) unsigned.

Можно ли синхронизировать это не меняя системный часовой пояс на всех серверах на одинаковый?

Понял. Я уже наклепал пару лишних функций на php, master_query(), slave_query() и т д, которые проверяют наличие подключения и выбирают сервера по списку в порядке приоритета, раз mysql-proxy заставлять работать нет смысла то перехожу на эту систему...

Поставь самопальный скрипт на морду, который не будет использовать БД и прочие дела, грузящие сервер, скрипт дает юзеру куку-флаги редирект на себя. Если после этого юзер пришел без куки - бан ему (блеклист), если с кукой - уже давай контент сайта. Должно помочь.

Как наиболее жесткий метод борьбы с ДДОС - закешировать весь контент и отдавать его nginx'ом, но над реализацией надо подумать. Я эту идею так и не реализовал, доведя только до уровня отдачи какой-то устаревшей страницы вместо последней актуальной в случае отсутствия ответа от БД по too many connections (когда-то такое было на хостинге)

Пока перевожу движок с php/mysql на mysqli. Будет 1 мастер и 2 слейва.

Вопрос выбора архитектуры: в php добавить проверку при проблемах с коннектом подключаться к другому серверу с кешем этого флага на файле (чтобы при падении каждое открытие страницы не ломилось на дохлый серв) + проверка куда слать запрос (запись в мастер, чтение на слейв) или подключаться только на localhost, где поставить mysql-proxy? Как лучше?

С одной стороны, пишут что mysql-proxy дает потерю производительности (хотя я не понимаю откуда, если и БД и прокси будут на одном VPS и пинг не должен расти), с другой мой самодел на php будет по сути повторять код mysql-proxy.

Дублирование данных must have это я уже решил, хотя Вы правы, вопрос скорее о выборе архитектуры. Я думал Master-Master, но меня уже почти убедили что лучше Master-Slave, 2 веб сервера. Падал mysql 2 раза за последние 3 или 4 месяца, один раз упал утром, а я об этом узнал только вечером когда добрался до компьютера. Скорость закачки с сайта зависит от географии, а посетители грубо говоря со всего мира. Плюс мало ли вдруг забуду вовремя продлить один из серверов. Плюс мало ли будет ддос атака на один из них или на соседей, а ляжет половина ДЦ.

MySQL proxy ставить или нет? Можно же подключаться ко 2 серверу при отсутствии коннекта к первому, а чтобы не ждать mysql connection timeout каждый раз - при пропадании сервера писать файл-флаг, который будет периодически устаревать, а до тех пор php будет подключаться к альтернативному серверу - итого при проблемах только 1 страница будет открываться 30 секунд, остальные быстро.

У меня нет опыта работы с репликацией, потому и начал с того что прошу совета тех, у кого опыт есть.

Т.е. рекомендуете делать master-slave и 2 постоянных коннекта от php 1 для SELECT (рандом мастер-слейв) и 2й для UPDATE / INSERT (только мастер) в предположении что когда мастер упадет сайт работать будет но не будет обновляться?

Всего: 575