Я провожу тест производительности на каком-то тяжелом SQL-скрипте, запущенном на postgres 8.4 в ubuntu box (natty).
У меня довольно нестабильная производительность, хотя предполагается, что я единственный, кто работает на машине (один и тот же сценарий с теми же данными может работать через 20 минут, а затем через 40 минут без какой-либо конкретной причины).
Итак, вспоминая свое далекое обучение администратора баз данных, я решил очистить кеш postgres, используя sudo /etc/init.d/postgresql restart, но все равно шатко!
Мой вопрос: может быть, мне не хватает кешей на моем диске / ОС? Я использую устройство NetApp в качестве хранилища. Я на правильном пути? Хочу ли я даже убедиться, что получаю стабильную производительность, прежде чем приступить к настройке?
Если ваше хранилище подключено к сети, то активность в сети и устройстве хранения может изменить ваши результаты. В конфигурации, которую вы используете, задействовано несколько уровней кэширования.
В вашем случае я бы ожидал, что кеши O / S и netapp могут быть факторами. Скорее всего, это доступ к данным с устройства netapp.
Многие из них трудно смыть. По моему опыту, очистка кешей не так уж и полезна. Если вы не выполняете запрос в другой неиспользуемой базе данных / сервере, существует множество факторов, которые будут иметь большее влияние на ваши результаты.
Даже если вы единственный пользователь в системе, есть задания cron, которые периодически запускаются и используют ресурсы. Посмотрите, получите ли вы более стабильные результаты, если запустите тест через такое же количество минут вне часа (9:15, 10:15, 11:15 ...).
Вы можете настроить munin server, чтобы следить за вашим тестовым сервером и видеть, есть ли у вас похожие профили во время разных запусков. Бег sar в фоновом режиме может предоставить полезную информацию об узких местах. sar обеспечивается atsar пакет.
В Linux вы можете использовать sync && sysctl vm.drop_caches=3 для удаления кэша страниц, dentries и inodes.