Как уже упоминалось ранее, наиболее узким местом для производительности является поиск на диске. Эта проблема становится все более и более очевидной по мере того, как объем данных увеличивается настолько, что эффективное кэширование становится невозможным. Для крупных баз данных, где доступ к данным осуществляется более или менее случайным образом, можно с уверенностью сказать, что потребуется по меньшей мере один поиск по диску для чтения и пара поисков по диску для записи некоторой информации. Чтобы свести эту проблему к минимуму, следует использовать диски с малыми временами поиска. Можно увеличить количество доступных дисковых "блоков" (и, таким образом, уменьшить нагрузку на диски). Это делается либо путем установления символических ссылок на разные диски, либо использованием RAID (stripe). Использование символических ссылок Это означает, что создаются символические ссылки индекса и/или файла/файлов данных из обычного каталога данных на иной диск (для которого, помимо этого, можно использовать RAID (stripe)). Применение символических ссылок улучшает как время поиска, так и время чтения (если эти диски не используются для других операций). См. раздел Использование символических ссылок. Использование RAID (stripe) Использование RAID (stripe) подразумевает, что при наличии нескольких дисков первый блок данных помещается на первом диске, второй блок - на втором диске, N-ный блок на диске с номером, равным остатку от целочисленного деления количества блоков N на число дисков, и т.д. При этом подразумевается, что если нормальный размер данных меньше, чем размер RAID-блока (или в точности равен ему), то производительность будет намного лучше. Следует учитывать, что процесс разделения дисков на RAID-блоки в значительной степени зависит от операционной системы и размера RAID-блока. Поэтому тесты производительности конкретного приложения необходимо производить для разных размеров RAID-блока (см. раздел Использование собственных тестов). Следует также учитывать, что разница в скорости при разделении дисков на RAID-блоки сильно зависит от заданных параметров. В зависимости от того, как установлены параметры разделения на RAID-блоки и каково количество дисков, можно получить величины с разницей в несколько порядков. Следует помнить, что необходимо выбрать оптимизацию отдельно для случайного и отдельно для последовательного доступа. Для надежности можно использовать режим RAID 0+1 (разделение на RAID-блоки + зеркальное отображение), но в этом случае будет необходимо 2*N дисководов для хранения информации N дисководов данных. Если возможности позволяют, то такой вариант выбора - наилучший! Однако при этом могут понадобиться также инвестиции и в программное обеспечение для эффективного управления этим объемом оборудования. Существует еще одна неплохая возможность: хранить не слишком важные данные (которые могут быть воспроизведены) на диске RAID 0, а действительно важные данные (такие как информация о хостах и журналы) - на диске RAID 0+1 или диске RAID N. Использование RAID N может оказаться проблемой, если у вас много операций записи, потому что обновление битов четности занимает время. Можно также задать требуемые параметры для используемой базой данных файловой системы. Легко поддается изменению монтирование файловой системы с опцией noatime. Использование этой опции позволяет пропускать обновление при последнем обращении в данном режиме и тем самым избежать поиска по диску. Под Linux можно получить намного большую производительность (под нагрузкой нередко вплоть до 100%), используя hdpram для конфигурации интерфейса диска! Приведенные ниже опции для hdparm зарекомендовали себя как очень полезные для MySQL (и, возможно, для многих других приложений): hdparm -m 16 -d 1 Следует учитывать, что производительность/надежность при использовании приведенных выше рекомендаций зависит от конкретного оборудования, так что мы настоятельно рекомендуем вам основательно протестировать систему после использования hdparm! Для получения более подробной информации о применении hdparm, обращайтесь, пожалуйста, к соответствующей странице руководства! Некомпетентное применение hdparm может привести к разрушению файловой системы. Прежде чем экспериментировать, сделайте полную резервную копию! Во многих операционных системах можно монтировать диски с флагом async - для того, чтобы данная файловая система могла обновляться асинхронно. Если ваш компьютер достаточно стабилен, это должно обеспечить повышение производительности без слишком большой потери надежности (под Linux этот флаг включен по умолчанию). Если нет необходимости знать, к какому файлу было последнее обращение (что реально не используется на сервере баз данных), можно смонтировать файловые системы с флагом noatime. Вперед  >>>  1  2   8  Комментарии к статье  8 8  Обсудить в чате

8  В тему Oбзор оптимизации Оптимизация SELECT и других запросов Вопросы блокировок Оптимизация структуры базы данных Оптимизация сервера MySQL