Вопросы Теги

Как Вы отслеживаете и отлаживаете проблемы производительности MySQL?

Нет, не помещайте свои частные IP-адреса в общедоступный DNS.

Во-первых, это пропускает информацию, хотя это - относительно незначительная проблема.

Худшая проблема, если Ваши записи MX указывают на ту конкретную запись хоста, состоит в том, что любой, который действительно пытается отправить почту в нее, в лучшем случае получит тайм-ауты доставки почты.

В зависимости от почтового программного обеспечения отправителя они могут получить возвраты.

Еще хуже, если Вы используете адресное пространство RFC1918 (который Вы должны в Вашей сети) и отправитель также, существуют все шансы, что они попытаются поставить почту своей собственной сети вместо этого.

Например:

  • сеть имеет сервер внутренней почты, но никакое разделение DNS
  • администратор поэтому помещает и общедоступные и внутренние IP-адреса в DNS
  • и записи MX указывают обоим:
 $ORIGIN example.com
 @        IN   MX    mail.example.com
 mail     IN   A     192.168.1.2
          IN   A     some_public_IP
  • кто-то видящий это мог бы попытаться соединиться с 192.168.1.2
  • лучший случай, это возвращается, потому что у них нет маршрута
  • но если они также получили сервер с помощью 192.168.1.2, почта перейдет к неправильному месту

Да, это - поврежденная конфигурация, но я видел, что это (и хуже) происходит.

Нет, это не отказ DNS, это просто делает то, чему это сказано.

6
задан 30 April 2009 в 14:26
3 ответа

Существует два отличных плана нападения выполнить с при диагностировании этих типов ошибок:

Во-первых, существует потенциал, что это - проблема, касающаяся фактического используемого программного обеспечения: что-то является чрезвычайно неопытным соединения и не выпуск их назад (или вообще с точки зрения зависающего потока, или за разумное количество времени с точки зрения медленного запроса).

Журнал медленного запроса очень выгоден в диагностировании проблем, но Ваше значение 15 секунд рядом с бесполезным: если запрос занимает 15 секунд затем, Вы - симпатичная завинченная точка. Как правило ползунка, я ищу запросы, занимающие больше чем одну или две секунды для выполнения. Работа через то, что обнаруживается в этом журнале с помощью ОБЪЯСНИТЬ ключевого слова и взгляда на то, что вызывает замедление (плохие соединения, сортируя необходимость во временной таблице и т.д.) - некоторое умное волшебство с кэшированием запроса и индексами, может часто выручать, если не возможно пойти глубже и переделать код / проектирование баз данных.

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

Во-вторых, необходимо заняться расследованиями, если конфигурация программного обеспечения виновата. Сколько параллельных соединений Вы испытываете? Каково фактическое количество макс. набора соединений к в mysql. Это может быть что-то столь простое, как апач служит, говорят, что 100 параллельных запросов, в то время как mysql только настроен для принятия 20 соединений - очевидно, что-то собирается дать. Если можно измерить, сколько трафика Вы ожидаете обрабатывать, то просто требуется некоторый здравый смысл (и иногда тире Google для нахождения корректной установки) для балансировки всех компонентов.

6
ответ дан 3 December 2019 в 00:24
  • 1
    Я не уверен, относится ли Ваш комментарий приблизительно 15 секунд, будучи слишком длинным к базам данных Bugzilla. Некоторые запросы там могут действительно занять время, просто посмотреть bugzilla.mozilla.org и искать некоторое общее обозначение на нескольких продуктах. –  Palmin 16 May 2009 в 23:07
  • 2
    15 секунд были комментарием в целом о веб-приложениях - если Bugzilla обычно берет, это жаждет запросов затем должно быть что-то серьезно неправильно с ним период. –  Ian 17 May 2009 в 16:54

Сколько апачских рабочих Вы имеете? Как, каковы макс. подключения mysql, которые Вы позволили? Поскольку апач порождает процесс cgi на httpd рабочего при обрабатывании запроса затем f, первый больше, чем последние апачи могут открыть больше соединений, чем mysql позволит.

Я предложил бы следующие настройки входа

log_slow_queries
log-queries-not-using-indexes
set-variable = long_query_time=1
1
ответ дан 3 December 2019 в 00:24
  • 1
    Максимальное количество httpd рабочих потоков I don' t знают (как я узнал бы это?). max_connections установлен на 100, но я сомневаюсь, что в любое время существует больше чем 1 000 процессов httpd. –  Palmin 30 April 2009 в 14:50

Задание крона для дампа очень полезно, но на всякий случай Вы не делаете наличие чего-либо готового к на самом деле изображает вещь в виде графика, я могу рекомендовать munin, который имеет плагины MySQL для контроля

  • пропускная способность
  • запросы
  • размер баз данных
  • медленные запросы
  • потоки

который может довольно полезный для определения скачков. Я выполняю через пять минут интервал по умолчанию.

Используя его за прошлый год я обнаружил довольно интересную ситуацию с ним, перед которой передал бы абсолютно незамеченный иначе.

1
ответ дан 3 December 2019 в 00:24

Теги

Похожие вопросы