Все там сразу появляется. Может у вас несколько серверов ?
Делайте тогда полный рестарт, если думаете что вам поможет.
а вот нельзя. все что нашел я - постоянные просьбы и постоянные отказы от разработчиков.
Когда я менял, у меня не было 40%. Просто редкие хиты от поисковиков. К сожалению, не измерил.
Может у вас зона не сразу обновилась на других серверах ?
Outsourcenow, сначала расскажите как в bind испортить TTL не залезая в исходный код. Мне кажется, вы или неправильно переносили или что-то не так считали.
Есть еще спамеры, поисковики и прочая шушера, которая экономит на днс-трафике. У них специальное клиентское ПО. Эти обойдутся.
Outsourcenow, ну откуда у вас данные о 40% ? Записи NS в .ru действительно с гигантским TTL, но тут ведь они в этой схеме не изменяются вообще.
Схема нормальная, только любой из трех серверов должен быть готов обслуживать запрос в любой момент. Если сайт сделан на распространенной CMS, это может оказаться непросто. Поэтому нужно изобретать что-то новое.
вы так быстро делаете выводы ?
Если ваши соединения "утекли", то пока процессы apache не завершатся, эти соединения не закроются. Можете из phpmyadmin запускать команду show processlist и наблюдать за своими соединениями. И даже по одному удалить : kill NNNN; там в первой колонке идентификатор соединения.
Время подключения не должно быть больше времени обработки странички.
IQPartner, ах простите, но вы ничего с этим не сделаете. Это форум, а не ваша личная тендерная площадка.
И кроме того, вообще ваши требования нуждаются в корректировке. Вот мы их и обсуждаем.
Например, поискать в коде вызовы mysql_pconnect и заменить на mysql_connect.
dex,я считаю, довольно неплохой результат эти 2-3 часа простоя в год. а от остальных неожиданностей конфигурация за 2000 спасает.
dex, к счастью, я не в курсе событий. там полностью отключали электричество на неделю и были выкрадены сотни серверов или как все было?
сколько откатите за перепродажу вам бесплатного движка wikipedia ?
а хотя если вам и наполнить, то уже все сложно
