БД (SQL) автоматизированные инструменты нагрузки / нагрузки?

Question

Я хочу измерить производительность и масштабируемость моего приложения БД. Я ищу инструмент, который позволил бы мне запускать множество операторов SQL для моей БД, принимая файл БД и сценария (SQL) в качестве аргументов (+ необходимые сведения, например, имя хоста, порт, логин ...).

В идеале он должен позволять мне контролировать параметры, такие как количество моделируемых клиентов, продолжительность теста, рандомизировать переменные или выбирать из списка (например, SELECT FROM ... WHERE value = @var, где var читается из командной строки или рандомизируется за исполнение). Я бы хотел, чтобы результаты теста были сохранены в виде файла CSV или XML, который я могу проанализировать и построить их. И, конечно же, с точки зрения цен, я предпочитаю «бесплатно» или «демо»: -)

Удивительно (по крайней мере для меня), хотя существует множество таких инструментов для нагрузочного тестирования веб-приложений, я не смог найти ни одного для тестирования БД !? Те, которые я видел, такие как pgbench, используют встроенную БД на основе некоторого сценария TPC, поэтому они помогают проверить конфигурацию СУБД и H / W, но я не могу проверить МОЮ БД! Есть предложения?

В частности, я использую Postgres 8.3 в Linux, хотя я мог бы использовать любой универсальный инструмент DB, соответствующий этим требованиям. H / W имеет 32 ГБ оперативной памяти, а размер основных таблиц и индексов составляет ~ 120 ГБ. Следовательно, может быть соотношение времени отклика 1:10 между холодным и теплым кэшем (ввод / вывод против оперативной памяти). На самом деле я ожидаю, что запросы будут распределяться равномерно, поэтому для меня важно проверить запросы к различным частям БД.

Не стесняйтесь также связаться со мной по электронной почте. Спасибо!

- Шауль Дар (info@shauldar.com)

Answer 1

JMeter от Apache может обрабатывать серверы разных типов. Я использую его для нагрузочных тестов против веб-приложений, другие в команде используют его для вызовов БД. Его можно настроить разными способами, чтобы получить необходимую нагрузку. Его можно запускать в режиме консоли и даже кластеризовать с использованием разных клиентов, чтобы минимизировать издержки клиента (и, таким образом, фальсифицировать результаты).

Это Java-приложение, и на первый взгляд немного сложное. Но все же мы любим это. : -)

Answer 2

SQL Load Generator - еще один такой инструмент:

http://sqlloadgenerator.codeplex.com/

Мне это нравится, но у него пока нет возможности сохранить настройки теста.

Answer 3

Вы проверяли Bristlecone с открытым исходным кодом от Continuent? Я не пользуюсь им, но он работает для Postgres и, кажется, способен выполнить то, что вам нужно. (извините, как новый пользователь, я не могу дать вам прямую ссылку на страницу инструмента, но Google доставит вас туда; o])

Answer 4

Мы так и не нашли адекватного решения для стресс-тестирования нашей базы данных DB2 на мэйнфреймах, поэтому мы в итоге развернули свою собственную. На самом деле он состоит из банка из 30 компьютеров под управлением Linux с установленной DB2 Connect.

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

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

Все это делается с bash и DB2 Connect, поэтому его довольно легко обслуживать (и бесплатно).

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

В настоящее время мы изучаем, можем ли мы объединить все эти физические серверы в виртуальные машины как на мэйнфрейме, работающем с zLinux (который будет использовать HyperSockets с разделяемой памятью для TCP / IP, в основном устраняя сетевые задержки), так и на платформах Intel с VMWare, чтобы освободить часть этого оборудования.

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