Баланс

[Zelenov]

Развиваемся! И даже чувствуется задел на будущее. А ведь уже скоро настанет тот день, когда понадобится подключать третий сервер. Интересно, какое будет у него название?

[rossomachin]

Edgar Hoover

[juks]

Sega

[justpro]

офигенное название, что-нибудь так-же назову, можно?)

[juks]

Можно конечно :-)

Я вообще хотел написать про это, собрать фольклёр, что ли, но решил что как-то глупо.

Одно из требований к названию это то, что его должны хорошо воспринимать по телефону люди из датацентра :-)

[CurlyBrace]

Игорь, мне кажется про фольклор было бы интересно многим )

[chepulis]

Предлагаю Chucky.

[KiNDER]

можно: Чак Норис

[Kurimochi]

Билл, Стив, Линус (Билли, Стиви, Линуська(?) )

[shalomman]

Back-end Сервер баз данных — «Анатолий Вассерман»

[juks]

у нас есть сервер Gena

[glader]

И женщина Люба: D

[void]

а у нас cerf

[kilg]

сделайте конкурс на имя нового сервака

[Zelenov]

Да можно прямо тут провести. Мои предложения (по-аналогии): Godfather, Scarface.

[KRen]

Почему-то вспомнились три поросенка =))

[workless]

33 Богатыря, с ними дядька суперсервер Черномор

[glader]

маршрутизатор

[egorinsk]

А можно поинтересоваться (не совсем по теме, но все же): применяется ли на Хабре кеширование страниц (например, текста топиков) и эффективно ли оно, если применяется? Или тут его не применить из-за обновления комментариев и прямого эфра?

[ur001]

Если бы не применялось 2 сервера бы не спасло.
Применяется, причём достаточно сильное и многоуровневое

[egorinsk]

А можно примерно хотя бы узнать, где? Очень любопытно) Если, конечно это не страшная военная хабратайна))

[ur001]

Кеширование НЕ применяется только в некоторых случаях при выдаче постов

[Aist]

Например, если зайти гостем «на морду», то к базе будет 0 запросов в 99.9% случаев.

[egorinsk]

o_0 круто)

[MajestiC]

А можно узнать механизм smartSet/smartGet?

[Aist]

Если говорить именно о механизме, то «умные» запросы к memcached позволяют избежать ситуации, когда данные устарели в кеше и приходит несколько запросов, последовательно пытающихся получить данные и записать их в кеш. Если данные устарели, то лишь первый запрос пойдет их обновлять, а остальные запросы будут получать устаревшие данные, пока ушедший за обновлением запрос не отработает :) Поэтому smartSet/smartGet используется не всюду, а лишь там, где не критично получать «немного старые данные».

ЗЫ Juks, молодец! Этого нам не хватало очень сильно.

[kabachok]

а где он был? o_0

[murr]

Хабратипограф не даст бездумно скопипастить Хабракод :)

[Trave]

if(! is_array($connections)) throw new Exception('connectFree: передан некорректный массив соединений');
некорректный или не массив? :)

[ItGold]

На следующем этапе перестанете изгаляться и поставите нормальный load-balancer.

[Aist]

Случится это при запуске мегахабра, никак не раньше :) При данных задачах «нормальный load-balancer», пожалуй, избыточен.

[ItGold]

Будем надеяться что это случится как можно раньше :)

[juks]

не один нормальный MySQL load-balancer, боюсь, за несколько часов не поставить. У них у большинства имеются свои ограничения на программную часть, как минимум, скорее всего придётся писать свой межсерверный join

[magicdream]

// Поиск минимального значения
if((!$minLoad && $status >=) || ($status > && $status < $minLoad))

И эта строчка работает? :)

[juks]

куда-то снесло часть значений при покраске

[Kigorw]

Fowler Refactoring — код подошел бы для книжного примера.

[freehome]

интересно
«Сохренение значения» порадовало )

[kurokikaze]

Очень интересно. Потом на свежую голову вчитаюсь в код получше.

[glader]

«проверяем статус репликации»
Смотрите отставание от мастера?

[juks]

Отставание пока нет, надо конечно, но пока только статус. В деле существенное отставание бывает только когда слейв догоняет мастера после восстановления репликации

[juks]

уже есть :-)

[glader]

Извини, туплю. Что ты имеешь в виду под «статусом»? Какую цифру?

[juks]

mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.3
Master_User: replication
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: clyde-relay-bin.000011
Read_Master_Log_Pos: 698473286
Relay_Log_File: bonnie-relay-bin.000022
Relay_Log_Pos: 698473429
Relay_Master_Log_File: clyde-relay-bin.000011
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: superhabr
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 698473286
Relay_Log_Space: 698473429
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
1 row in set (0.00 sec)

[glader]

А ларчик просто открывался :)
Спасибо

[glader]

«При каждой инициализации средств работы с базой данных»
Один раз на запрос? Чаще? Реже?

[aleks_raiden]

это уже есть :) сеттеры и геттеры уже везде почти :) :) :)

[juks]

Это базовый класс низкого уровня. В проекте думать про соединение вообще не надо.

[juks]

$users = new HabrUsers();
$user = $users->getOne(array('login'=>$login));

echo $user['email'];

[gkirok]

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

[juks]

Clyde: два Xeon 1.6 по 4 ядра в каждом. 6 гигабайт памяти, два SAS диска по 74 гигабайта. FreeBSD 6.2. Mysql 5.0.67

[gkirok]

спасибо

[maghamed]

Скажите, %juks%, а может быть имело смысл вынести такую логику по коннекту к определенному DB серверу и выбору менее загруженного, скажем в отдельный скрипт, и запускать его по крону, чтобы он обновлял статистику в memcached актуальными данными. Ну и поставить интервал запуска скрипта в соответствии с Вашим $cacheTime = 35;. А в рабочих скриптах уже просто выгребать данные из кеша. В которых бы лежали статистика по каждому из серверов. Что Вы думаете по данному поводу?

[juks]

Я думаю, что это уже на любителя. Я стараюсь делать меньше крон-задач, меньше нагромождения.

Текущая реализация схожа по работоспособности с тем, что вы предлагаете, просто действует «on demand». Как-нибудь, может напишу про smartGet и smartSet, там всё элементарно, но в действительности спасает от лишних запросов к базе.

Если не кешировать запросы вообще, то это добавляет по 20% нагрузки CPU на каждый сервер. С кешированием дополнительная нагрузка незаметна. Как получить отдельно число работающих тредов без сбора всей статистики целиком я так и не нашёл.

[juks]

Кстати, вспомнил.

У крона ведь дискретность одна минута, у Memcached — секунда. Даже при периоде в 5 секунд, время от времени имеет место некоторая «раскачка» нагрузки от сервера к серверу.

Так что если выносить, то надо делать отдельный демон.