Приветствую, Sinclair, вы писали:

S> S>Ты вот ругаешь и ругаешь, но ничего кроме поливания я тут не вижу. Может начнешь конструктив приводить?
S> Я уже привёл конструктив. Вместо "текстовых конфигов" для хранения конфигураций такого масштаба применяется распределённая реляционная СУБД.

Где это реализовано?

Приветствую, Sinclair, вы писали:

S> S>При чем тут масштабирование? Я дал решение "проблемы", которую придумал мамут.
S> Эту проблему придумал не мамут, а авторы апача. Масштабирование — это такое слово, о котором ты, как админ, должен знать. Если себя хоть на волос профессионалом считаешь.

Не уходи от темы. При чем тут масштабирование? Решил увести разговор в сторону?

Здравствуйте, Sheridan, Вы писали:
S>Тоесть всетаки я прав — зависит от железа, так?
Всё-таки нет.

S>Покажи мне хостера с миллионом сайтов
godaddy, 1and1, netfirms.
Hostgator ~ полмиллиона сайтов и быстро растёт.

S>А теперь расскажи как ты к этому пришел. При чем тут конфиги?
Экспериментальным путём. Конфиги, как я уже полветки объясняю, становятся боттлнеком в таких конфигурациях. Потому что на их перечитывание при изменениях уходит непозволительно много времени. Вообще идея "зачитать всё в память при старте", которую тут предлагал Антон Батенёв, утопична при высокой загрузке.

S>Я не переношу, не бойся.
Я не боюсь. Но ты — переносишь. Потому что решения, которые ты предлагаешь, в среде под высокой нагрузкой вообще не будут жить. Там этот твой "релоад" будет запускаться четыре раза в секунду, и требовать часы для завершения.

S> M> S> M> Апач в жизни не сможет захостить миллион простых сайтов.
S> M> S> Зависит от железа.
S> M> не зависит. не сможет

S> Ты ссылку забыл дать.

Ответ рядом у Антона Батенева

Захостить сможет, работать сможет, но 1 млн. сайтов даже по 10 хитов на динамику в день создадут на нем неподъемную нагрузку.

Апач не является самым производительным сервером в мире


S> M> S> M> И полноценной горячей замены ни в апаче ни в nginx'е нет.

S> M> S> Что ты понимаешь под этим?

S> M> добавь новый сайт в httpd.conf/nginx.conf и чтобы усе сразу поехало

S> Гм, я бы следил по inotify\dnotify за конфигами и по изменению делал рестартовал апач с -k graceful, чтобы соединения не рвало. Скрипт написать можно имхо за полчаса... Точнее не скрипт, а программулину. Неважно в общем.

Ну, это уже костыль на костыле

S> А вообще редко имхо нужно бывает так часто сайты добавлять\удалять. Разве что крупным хостерам...

Синклер о таких и говорил

S> S> S>При чем тут масштабирование? Я дал решение "проблемы", которую придумал мамут.

S> S> Эту проблему придумал не мамут, а авторы апача. Масштабирование — это такое слово, о котором ты, как админ, должен знать. Если себя хоть на волос профессионалом считаешь.

S> Не уходи от темы. При чем тут масштабирование? Решил увести разговор в сторону?

Миллион хоcтов — это и есть масштабирование (a.k.a. scaling)

Здравствуйте, Sheridan, Вы писали:
S>Где это реализовано?
У 1and1.сom. Доступа до информации об остальных у меня нет. Но, смею полагать, что они тоже сильно допилили коробочные решения.

Здравствуйте, Sheridan, Вы писали:
S>Не уходи от темы. При чем тут масштабирование? Решил увести разговор в сторону?
Это ты решил увести разговор в сторону.
Напоминаю: вот я пишу

Мне нужен DNS-сервер, который бы хорошо масштабировался и был отказоустойчивым. И нужен веб-сервер, который позволяет хостить миллионы простых сайтов с горячей заменой. И всё это должно работать на минимальном количестве железа.

Мамут подсказывает:

Апач в жизни не сможет захостить миллион простых сайтов. И полноценной горячей замены ни в апаче ни в nginx'е нет. Их надо пинать, чтобы они заново считали конфиги

Ты ему в ответ предлагаешь:

Гм, я бы следил по inotify\dnotify за конфигами и по изменению делал рестартовал апач с -k graceful, чтобы соединения не рвало. Скрипт написать можно имхо за полчаса... Точнее не скрипт, а программулину. Неважно в общем.

И вот на это я тебе медленно объясняю: нет, не будет это работать для миллиона сайтов. твой рестарт с -k graceful перестанет обслуживать сайт ещё примерно при одной тысяче в-хостов.

Ну и кто теряет нить разговора? И кто тут обвиняет программистов в том, что они пишут какие-то неправильные программы? Ты вот только что спроектировал программу, которая убъёт апач на корню при мало-мальски заметной нагрузке. Нет, я не спорю — она прекрасно подойдёт для сайта заборостроительной конторы, который хостится у тебя дома на выделенном пентиуме. Тут всё будет в порядке — действительно, деплоймент копированием и всё такое.
А в боевом сервере с высокой плотностью этот твой graceful — что мёртвому припарка. Потому, что существующие соединения (а их очень немного) никого не интересуют — новые соединения не будут приниматься вплоть до окончания загрузки апача и его конфигов. Грубая прикидка количества необслуженных запросов — O(N^2), где N — количество сайтов. Потому, что время подъема апача линейно от него зависит, и частота запросов линейно зависит от него же.

Так что graceful можно не указывать; он спасёт ничтожно малый процент запросов.

Приветствую, Sinclair, вы писали:

S> S>Тоесть всетаки я прав — зависит от железа, так?
S> Всё-таки нет.
Тоесть, гипотетически, если у меня будет комп с терабайтом оперативки, быстрым рейдом и 4 тысячами процессоров (ну вобщем "очень крутой сервант" (ц) ) — сколько получится поднять vhost'ов?

S> S>Покажи мне хостера с миллионом сайтов
S> godaddy, 1and1, netfirms.
S> Hostgator ~ полмиллиона сайтов и быстро растёт.
Итого три с половиной. Еще есть?

S> S>А теперь расскажи как ты к этому пришел. При чем тут конфиги?
S> Экспериментальным путём. Конфиги, как я уже полветки объясняю, становятся боттлнеком в таких конфигурациях. Потому что на их перечитывание при изменениях уходит непозволительно много времени. Вообще идея "зачитать всё в память при старте", которую тут предлагал Антон Батенёв, утопична при высокой загрузке.
Идея самостоятельно перечитывать при изменениях — еще более утопична, где бы эти конфиги не находились.

S> S>Я не переношу, не бойся.
S> Я не боюсь. Но ты — переносишь. Потому что решения, которые ты предлагаешь, в среде под высокой нагрузкой вообще не будут жить. Там этот твой "релоад" будет запускаться четыре раза в секунду, и требовать часы для завершения.
4 раза в секунду будут добавлять\удалять vhost'ы? Ну-ну.
И насчет "часы для завершения" — реальные цифры покажи с -k graceful, а не предположения. Ты же не любишь предположения, не так-ли?

Здравствуйте, Sinclair, Вы писали:

C>>Умм... А "/etc/init.d/apache reload" чем не угодил?
S>А ты время померь. И прикинь, сколько это будет времени, если у тебя миллион vhost.
А не пофиг? Во время перезагрузки оно продолжает работать со старым конфигом. Так что всё нормально, если оно будет занимать меньше минуты.

Здравствуйте, Sinclair, Вы писали:

S>>Покажи мне хостера с миллионом сайтов
S>godaddy, 1and1, netfirms.
S>Hostgator ~ полмиллиона сайтов и быстро растёт.
На одной машине?

Здравствуйте, Cyberax, Вы писали:
C>А не пофиг? Во время перезагрузки оно продолжает работать со старым конфигом. Так что всё нормально, если оно будет занимать меньше минуты.
Неа. Не продолжает. Тупо новые коннекты реджектятся. И я сомневаюсь, что загрузка одного миллиона вхостов из конфига займёт меньше минуты.

Здравствуйте, Cyberax, Вы писали:
S>>>Покажи мне хостера с миллионом сайтов
S>>godaddy, 1and1, netfirms.
S>>Hostgator ~ полмиллиона сайтов и быстро растёт.
C>На одной машине?
В одном кластере. Я же говорю — вопрос в горячей замене, чтобы смерть одного апача не приводила к простою двадцати К сайтов.

Приветствую, Mamut, вы писали:

M> S> S> S>При чем тут масштабирование? Я дал решение "проблемы", которую придумал мамут.
M> S> S> Эту проблему придумал не мамут, а авторы апача. Масштабирование — это такое слово, о котором ты, как админ, должен знать. Если себя хоть на волос профессионалом считаешь.
M> S> Не уходи от темы. При чем тут масштабирование? Решил увести разговор в сторону?
M> Миллион хоcтов — это и есть масштабирование (a.k.a. scaling)

Так мы про масштабирование или про автоматический релоад апача в данной ветке, а? Вы определитесь. Лично я тут дал вариант релоада апача автоматически при изменении конфигов.

Приветствую, Sinclair, вы писали:

S> И вот на это я тебе медленно объясняю: нет, не будет это работать для миллиона сайтов. твой рестарт с -k graceful перестанет обслуживать сайт ещё примерно при одной тысяче в-хостов.
Может быть, я не пробовал. Покажи лог релоада апача с миллионом сайтов.

S> Так что graceful можно не указывать; он спасёт ничтожно малый процент запросов.
А кто говорил что будет легко?

Ты пока что твердишь что все исправит СУБД для конфигов, хотя на самом деле надо копать не в источник конфигов, а в код перечитывания конфигов. А откуда оно их читать будет — без разницы.

Приветствую, Mamut, вы писали:

M> S> M> S> Зависит от железа.
M> S> M> не зависит. не сможет
M> S> Ты ссылку забыл дать.
M> Ответ рядом у Антона Батенева
Я знаю. Я пытаюсь понять почему ты безаппеляционно говоришь "нет". Причем потом показываешь на ответ рядом, и говоришь что он правильный, хотя там написано "да, но хрено-ово".

M> Апач не является самым производительным сервером в мире
Знаю.

M> S> Гм, я бы следил по inotify\dnotify за конфигами и по изменению делал рестартовал апач с -k graceful, чтобы соединения не рвало. Скрипт написать можно имхо за полчаса... Точнее не скрипт, а программулину. Неважно в общем.
M> Ну, это уже костыль на костыле
Я — не истина в последней инстанции. Предложи свой вариант.

M> S> А вообще редко имхо нужно бывает так часто сайты добавлять\удалять. Разве что крупным хостерам...
M> Синклер о таких и говорил
Три с половиной хостера пока набежало. Как набежит хотябы сотня — тогда и будем говорить. А пока что напомни как тут про линух говорят? "это меньше 1%, значит неважно" — так помоему?

Здравствуйте, Sheridan, Вы писали:
S>Тоесть, гипотетически, если у меня будет комп с терабайтом оперативки, быстрым рейдом и 4 тысячами процессоров (ну вобщем "очень крутой сервант" (ц) ) — сколько получится поднять vhost'ов?
А скорость света тоже считать равной бесконечности?

S>Итого три с половиной. Еще есть?
А тебе сколько надо?
http://websitehostingreviews.blogspot.com/2007/04/top-10-web-hosting-largest.html
Это устаревшая на 2 года информация. С тех пор всё только улучшилось.


S>Идея самостоятельно перечитывать при изменениях — еще более утопична, где бы эти конфиги не находились.
Увы, она работает. Реальные пацаны используют сразу всё — там и push, и pull model. Но в целом — таки да; изменения конфигурации насильственно пропихиваются прямо в память того апача, который сейчас отвечает за этот сайт. Никакого рестарта там нет.

S>4 раза в секунду будут добавлять\удалять vhost'ы? Ну-ну.
Ну, не во всякую секунду.

S>И насчет "часы для завершения" — реальные цифры покажи с -k graceful, а не предположения. Ты же не любишь предположения, не так-ли?
У меня как-то нет под рукой апача с миллионом хостов. Но я при случае замерю

Здравствуйте, Sinclair, Вы писали:

S>>>Hostgator ~ полмиллиона сайтов и быстро растёт.
C>>На одной машине?
S>В одном кластере. Я же говорю — вопрос в горячей замене, чтобы смерть одного апача не приводила к простою двадцати К сайтов.
Этот вопрос я решил бы на уровне DNS и load ballancer'а. Так как в любом случае нужно будет обрабатывать умирание аппаратного узла.

Здравствуйте, Sinclair, Вы писали:

C>>А не пофиг? Во время перезагрузки оно продолжает работать со старым конфигом. Так что всё нормально, если оно будет занимать меньше минуты.
S>Неа. Не продолжает. Тупо новые коннекты реджектятся. И я сомневаюсь, что загрузка одного миллиона вхостов из конфига займёт меньше минуты.
Мда. Я был лучшего мнения об Апаче.

Зато проверил на nginx'е — он таки умеет не прерывать существующие соединения до перезагрузки конфига (опция ngx_new_binary). Т.е. посылаешь ему SIGHUP, и он просто запускает новый nginx, который наследует открытые сокеты старого, в том числе и сокет, на который идёт accept. И потом просто начинает на нём слушать, а старый nginx завершается после смерти всех worker process.

Здравствуйте, Sheridan, Вы писали:
S>> Так что graceful можно не указывать; он спасёт ничтожно малый процент запросов.
S>А кто говорил что будет легко?
Никто не говорил. А вот что с текстовыми конфигами будет тяжело — говорил я.

S>Ты пока что твердишь что все исправит СУБД для конфигов, хотя на самом деле надо копать не в источник конфигов, а в код перечитывания конфигов. А откуда оно их читать будет — без разницы.

Проблема — ровно в том, что код для перечитывания текстовых конфигов может быть только один.
СУБД, в отличие от текстовых файлов, позволяют запросить ровно то, что нужно — например, сделать

select root_dir from vhosts where hostname = @hostname

Напиши мне такой же "код перечитывания конфигов", построенный на основе текстовых файлов.

Здравствуйте, Cyberax, Вы писали:

C>Зато проверил на nginx'е — он таки умеет не прерывать существующие соединения до перезагрузки конфига (опция ngx_new_binary).
Апач тоже это умеет.
C>Т.е. посылаешь ему SIGHUP, и он просто запускает новый nginx, который наследует открытые сокеты старого, в том числе и сокет, на который идёт accept. И потом просто начинает на нём слушать, а старый nginx завершается после смерти всех worker process.
Начинать-то он начинает. Но что он делает с новыми соединениями до того, как дочитает конфиг?