2

Я уже разместил это в StackOverflow, но он был помечен как не по теме. Может быть, вы, ребята, можете мне помочь.

В настоящее время я делаю некоторые тесты базы данных на виртуальной машине под управлением Ubuntu 12.04. Я заметил, что во второй раз, когда я выполняю запрос, он запускается значительно быстрее. Скорее всего, это связано с кэшированием ОС, которое просто хранит все данные в основной памяти. Чтобы кэш не испортил мои измерения, я хочу очистить его между последующими прогонами.

Я нашел следующие команды для достижения этого в Google:

sync;echo 3 > /proc/sys/vm/drop_caches

а также

sysctl -w vm.drop_caches=3

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

Первая идея - перезагрузить компьютер между запусками, так как это очищает кеш. Поскольку я хочу выполнить пару десятков пробежек, мне действительно нужно автоматизировать это. Таким образом, я мог бы поместить программу в автозапуск, позволить ей выполнить запрос, перезагрузиться и продолжить следующий запрос при следующем запуске. Чувствуется, будто пишешь вирус.

Вторая идея - просто заполнить память другими данными. Так как на моей машине достаточно оперативной памяти, я бы, например, сгенерировал какой-то большой файл случайных данных и просто прочитал его в /dev /null.

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

Большое спасибо заранее, Антиго

1 ответ1

1

Этот вопрос, кажется, основан на предпосылке, что увеличение скорости во второй раз происходит «из-за кэширования ОС, которая просто хранит все данные в основной памяти». Я не был бы настолько уверен, что это единственная разница между первым и последующим запусками. Если разница в производительности была связана с кэшированием ОЗУ виртуальной машины, то разница с перезагрузкой виртуальной машины должна быть незначительной, и вам потребуется перезагрузить хост, чтобы увидеть разницу.

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

Если у вас достаточно ОЗУ для этого, одним из способов обойти кеширование было бы просто переместить файлы базы данных на большой RAM-диск на время ваших тестов. Отслеживая статистику ввода-вывода, вы можете оценить объем ввода-вывода, вызванный запросом, и, следовательно, влияние на производительность различных методов оптимизации, не беспокоясь о последствиях кэширования данных, поскольку все данные уже находятся в оперативной памяти. ,

Вы не говорите, какой движок базы данных у вас работает, поэтому сложно дать конкретные предложения. В Microsoft SQL Server вы должны сделать что-то вроде SET STATISTICS IO,TIME ON и / или SET STATISTICS PROFILE перед выполнением запроса, чтобы получить данные о том, насколько усердно должен работать сервер базы данных для выполнения рассматриваемого запроса; другие движки баз данных почти наверняка имеют аналогичные функции (это основная предпосылка для настройки производительности запросов). Обратите внимание, что такие статистические данные часто включают количество фактических запросов ввода-вывода и что эти запросы ввода-вывода могут, но не обязательно , выполняться из любого кэша на уровне ОС, эти цифры могут быть полезным индикатором объема данных. в выполнении запроса. Большие различия между планом запроса и фактическим результатом, особенно по количеству операций ввода-вывода или количеству строк в различных контекстах, будут влиять на производительность, поскольку это означает, что ядро базы данных принимает неверные решения о том, какие алгоритмы использовать. Большое количество I / O в любом месте может очень хорошо означать , что вы ударять диск больше , чем необходимо , которые придут на счет производительности.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .