On Thu, Nov 25, 2004 at 02:51:01PM +0200, Edward Melnik wrote:
On Thu, Nov 25, 2004 at 02:32:01PM +0200, Valentin Nechayev wrote:
Thu, Nov 25, 2004 at 14:26:37, edd wrote about "[uanog] Re: [q] SMP mashine. OS - ?":
Вообще же в такой ситуации я поставил два сквида впараллель друг другу и назначил два IP для прокси. Вместе с aufs (который, правда, на 4.* делался патчем через AIO+kqueue) стало совсем хорошо ;)) Не, ну я понимаю, что это способ. Но у меня 1 squid. И кстати, если я его собираю с --with-pthreads, то почему это до лампочки?
Потому что squid так написан. У него центральный цикл сетевого обмена сделан на одной центральной нити, а дополнительные нити/процессы используются для неблокирующего чтения с диска. Ставим вопрос по-другому - "переход на linux SMP мне позволит использовать Переход на linux smp позволит, возможно, получить более живучую под нагрузкой систему. CPU load balancing именно с 1 squid?" нЫкак. А в конструкции как я предложил (1 смотрит в N parents, паренты ходят в разные места - кэши не дублируются) есть свои неприятные грабли - типа даунлоадеров в кучу потоков - жрёт вагон полосы, delay pools ты на каждого клиента нормально не сделаешь - инфу о клиенте "вверх" можно только через то самое место передавать... Грабли решаемы, но я их решением по-нормальному не занимался. Если паренты хранят кэш (при по-доменной балансировке это имеет смысл) - то на каждого парента по диску/массиву, а то взлёт этой конструкции будет весьма тормозным(особенно, если все сразу пустить...). Если наоборот (клиенты идут в тот, что хранит всё, а паренты уже ходят "куда надо") - то на дисках сэкономить можно :).
2 сквида "впаралель" хреново либо появлением оверхеда на взаимные запросы, либо тем, что они независимые - и в итоге дублируют информацию.
Я такое видел еще в NT4 ;) Если тебе рисуют, что оба CPU заняты на 50% и имеем 1 задачу - значит один из них практически занят "ничем". Если чуть больше - то в системе тоже есть разные процессы, системные вызовы и другая всячина. Короче, я вот забиваю named9@xp2600 - 14-15% постоянной загрузки, при том что в него смотрят 3 таких же, а не куча клиентов. Далее он становится абсолютно неюзабкльным - резолвинг несколько секунд занимает. Это вобщем намёк, что если задача сводится к "чем бы занять" - то всегда есть чем, редиректоров штук 50 пустить умных сильно...
Короче - любая большая нагрузка описываема статистически. Если влом считать - подбирабельно эмпирически. Если решишь два паралельно - то просто клиентов одних в один, других - в другой. И сразу понятно, чего и где. Если клиентов транспарентом заворачивать - то можно по dst разрулить ipfw. Но это "кропотливый труд". -- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message