Это Вы мне писали?
Просто непонятно, какое отношение у гугла, если он рисует совсем левую статистику, лучше бы вообще не рисовал. :)
Если будем стараться для гугла, а не для пользователей, то ни фига не будет. :)
Вредный совет. Мы залезем в своп и потеряем кеш.
Нужно увеличивать постепенно, при этом, если упираемся в память и процессор, смысла увеличивать нету.
А также проверьте, нету ли ошибок, связанных с max_execution_time и slow_query_log. Они могут блокировать PHP и поэтому не остается свободных процессов.
И смотреть нужно не на суммарную посещаемость, а пиковую в те моменты, когда сыплются ошибки.
В mysql нету "WITH"
Каждый раз выбирать рендомом - большая нагрузка на базу, если она большая.
Что можно сделать:
а) выбирать допустим 10 случайных и кешировать их на час, а на приложении уже выбирать их согласно весов.
б) завести дополнительное поле "Накопительный вес".
Потом:
1) зная суммарный вес WeightSum,
2) генерируем случайное число $WeightRand = rand(0, Sum)
3) выбираем из базы запись с условием WHERE Weight > $WeightRand ORDER BY Weight ASC LIMIT 1
Минусы: при деактивации баннера нужно обновлять накопительные веса всем баннерам после него.
Собрать с исходников (сам так делал)
/ru/forum/930176
Если Вы не предоставляете услуги третьим лицам и есть мозги в голове, то я советовал бы обойтись без панелей и настраивать все руками в консоли. Не нужно будет пробиваться через глупости панели. :)
А смысл временные таблицы на tmpfs переносить?
Много памяти? Увеличьте размер временных таблиц в памяти.
В логах доступа Ваш паук?
Если да, то смысл было давать этот лог? :)
Там запросов больше 5 в секунду. То есть это вряд ли php задыхается.
Скорее всего до него запрос не доходит.
Да и обычно в случае недоступности бекэнда будет 502 ошибка.
Нужен лог ошибок, второй файл не похож на него, да и он скудный. :)
А также попробуйте перезапустить nginx и php.
Лучше использовать $_SERVER['DOCUMENT_ROOT'] и от него плясать.
Сколько времени прошло от переезда?
Возможен кеш ДНС.
Что говорят GWMT и ЯВМ?
