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

во первых, вовсе и не очевидно.
во вторых ты будешь когда разбирать первый запрос, ты и поймешь, что не так.

конфигурации "было" и "стало" сравнивали, надеюсь?

kayuchkinArhat109Можно предположить, что ПХП-клиент с одного сервера обращается к БД на другой ... или нет?


да, на самом деле сейчас происходит именно так, а это плохо? )

p.s.: сервера вроде как стоят рядом, в одном дата-центре

нет, это наоборот хорошо.

кроме того, вы же данные т. н. Бэкапом переносили, наверное? Статистику по таблицам собирали после загрузки данных?
индексы все создали?

Arhat109miksoft,

Я его выкачивать не стал, не увидел в нем ничего такого, кроме регулярных запросов с большим временем выполнения, и они все идут с левым джойном к 3 и более таблицам. Главная - разная, вторая всегда users, третья и т.д. - тоже зависят от запроса ... ни в одном нет проверки на IS NULL, как явный признак необходимости left join, и часто стоит WHERE 1=1, из чего делаю вывод, что они собраны "чем-то" (cakePHP - есть такой?) и надо ли там именно левый джойн - не очевидно.

Каждый такой тормозной запрос перелопачивает от миллиона записей. Часто результат к возврату - отсутствует. То есть результат выборки - пуст.

Мужчина, так вот и надо брать ПО ОДНОМУ эти вот запросы, и решать проблемы их производительности.
Бери сначала самый долгий. Не, не так. Частый (нужно знать приложение), но долгий. Т.е. если самый долгий -- редкий, его не бери.
Бери следующий по длительности, и так далее, пока не найдёшь часто выполняемый.
Его оптимизируй (надо понять, в чём проблема и её исправить).

И очень вероятно, что "ремонт" одного запроса потянет за собой исправление многих запросов.

ПОСЛЕ исправления -- очищаешь slow query log, ждёшь, когда он снова наполнится -- и снова повторяешь операцию (для следующего запроса).

Arhat109Вы на сайт ходили?
.

Мне твой сайт ни к чему. GUI морда ни о чём не говорит.

Arhat109Зачем рекомендовать человеку заведомо неграмотное решение? В каких конкретно случаях разнесение клиента и сервера БД дает прирост производительности?


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


Arhat109Как часто такое у означенных сайтов?

С каких пор передача по локальной петле в рамках одного железа стала хуже передачи по сети, пусть даже гигабитной между двумя компами?


А что, у вас между компами не гигабитная сетка на волокне ?

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

Не, ну, мужчина, как хочешь. Я тебе даю полезные советы, бесплатно, а там уж твоё дело, делать, как будет лучше, или себе же хуже.

Вообще, в принципе, когда БД и что-то ещё на одной машине -- производительность достаточно сложно отслеживать.
Даже в этом огромный плюс. Когда MySQL(или кто ещё) считает запрос, а тут поступает запрос в appach и он под себя берёт всё CPU вытесняя MySQL нафиг из проца, то тут что можно мониторить ?

Arhat109или обосновать и сделать полноценную реплику,

Реплика-то как производительности поможет ?

Arhat109MasterZiv,

вот это: Всегда. Это повышает вычислительные мощности системы. Примерно в 2 раза, если одинаковые серваки.

обоснуйте тупому, желательно с цифирьками.


Чего тебе обосновывать-то ?

У тебя один сервер. В нём скажем 16 гиг памяти и 8 процов.
Ты ставишь второй такой же -- суммарно получается 32 гиг памяти и 16 процов.

Скорость передачи данных между WEB-сервером и СУБД не должна быть такой уж критичной,
потому что от WEB-сервера в СУБД поступают запросы, их объём в видеданных маленький,
а обратно из СУБД в WEB-сервер идут только результаты этих запросов, которые также небольшие
по объему, если конечно приложение нормально спроектировано.

Да... а пацаны-то и не знают. Пасибки. То есть, ежели я поставлю 100 веб-морд и 100 SQL серваков, то мой сайт будет шустрее ровно ... в 200 раз? Круть. (побежал за железом)


при правильной архитектуре - да, почти в 200 раз.
по сравнению с одним таким компом и при бесконечно растущей нагрузке, естественно.

Вы так и НЕ ответили: во сколько РАЗ скорость гигабитной подсети промеж двух компов шустрее внутренней петли одного компа...

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

авторНет, так и НЕ ответили, а только виляете.

Ибо хорошо знаете, что скорость гигабитной сети никак не в состоянии превысить порог в 42 мегабайта в сек. (1000Мбит / 12бит / 2 - окно Ethernet), что даже ниже скорости средненького винчестера под виндой (60-80), а скорость внутренней петли измеряется сотнями метров, если не гектарами в ту же самую секунду. То есть это

самое медленное звено во всей последовательной(!) цепи обработки HTML-запроса (PHP_клиент - сеть - мускуль - ФС - мускуль - сеть - PHP_клиент).


Мужчина, ещё уже наверное 5-ый раз -- нет там между сервером приложений (WEB) и СУБД какого-то огромного траффика.
Не должно его просто быть в такой архитектуре. Он там мизерный.

авторА теперь следим за пальцами: был один сервер и он ... справлялся. Стало 2 и начались проблемы, что и явилось причиной появления автора тут... вы же пишете что его решение есть "хорошо".

Есть, и хорошо, но не для задач клиента.


Для клиента было бы хорошо, если бы он хоть один запрос опубликовал.

ScareCrowавторпри правильной архитектуре - да, почти в 200 раз.
а расскажите ка про эти секретные приборы?

Чё расказать та ?

Sharding, shared nothing cluster поищи, и почитай.