Hello, Nikolay!
Nikolay Ponomarenko wrote:
1. Сайт http://ibdeveloper.com/tests/tpc-c/ уже несколько дней помечен
как зараженный, что не останавливает, но волнует :)
запарили гады - уже второй раз заражают.
Мог бы и на support спросить. А то по сайтам-то все шастают,
а вот как письмецо написать - тут же "deadlock" возникает почему-то.
2. Батники http://www.ibdeveloper.com/download/TPCCKIT.zip теста требуют
легкой доработки напильником(несколько опечаток) - мелких, но сходу не
запустить :)
Дифф в аттаче.
а никто не обещал сладкой жизни. :-)
3. Странная деградация производительности к концу теста - если начинаем
с 3500-4000 операций в секунду, то к концу - это уже 800-900. Это так и
должно быть?
не помню, надо покопаться в памяти.
В итоге среднее значение для сервера 1500. В логе куча конфликтов - так
и должно быть?
ну да. там же туча конкурирующих клиентов создают накладные.
At procedure 'NEWORD2' line: 72, col: 3
см. процедуру.
4. На результат почти не влияет изменение конфигурации рейда:
6 дисков в RAID10 - TPC-C Throughput: 1100 - 1200 tpmC (IOMeter - 2600)
8 дисков в RAID0 - TPC-C Throughput: 1100-1200 tpmC (IOMeter - 4600)
я бы порекомендовал одновременно смотреть скорость чтения с диска,
байт в секунду, и скорость записи на диск, байт в секунду, а также
среднюю и текущую длину очереди диска, плюс загрузка проца.
Потому что эти иопсы или тпм-с не всегда дают полную картину.
Например, вы могли упереться в локи классика по процессору,
например как в играх -
если меняя разрешение не меняется FPS, то значит проц медленее
видеокарты. Если при изменении разрешения меняется FPS - значит
проца хватает, а видеокарты - не очень.
Т.е. все результаты tpc-c крутяться в диапазоне 1100 - 1200, вне
не смог пройти мимо - крутяТСя. "крутяться" - такого слова вообще нет.
есть "крутиться".
http://my-tribune.blogspot.com/2008/07/blog-post_08.html
зависимости от конфигурации рейда, размера страйпа и т.п. В то время как
синтетический тест IOMeter разницу показывает, и в некоторых случая
значительную.
насколько он грузит проц? Вы меня извините, я когда примитивные бэкапы
и ресторы тестирую, я смотрю на прорву параметров, чтобы понять,
где и что. Смотреть только на иопсы в иометре - это действительно
заценивать производительность ТОЛЬКО дисков. Но сервак это не только
диск, это еще и процессор. Ну и СУБД тоже не сферический конь.
(с) Капитан Очевидность.
Настройки теста - те, что идут по умолчанию(кроме страницы базы -
поставлена 16к). Во время теста загрузка процессоров минимальна.
В чем может быть причина таких неоднозначных результатов? Должно ли быть
столько дедлоков?
Есть ли где описание, как можно трактовать полученные в логе результаты?
Правильно ли я понимаю, что tpc-c - это по сути тестирование дисковой
подсистемы?
не-а. это тестирование того, как СУБД может загрузить конкретный сервак.
Если да, то почему изменение кол-ва дисков, изменение
конфигурации рейда почти не влияют на результат?
значит с какого то момента все упирается в проц. Типичный пример:
http://www.ibase.ru/devinfo/backupspeed.htm
у IB практически нет разницы между бэкапом через services API
на тот же диск или на другой (физический).
Это потому, что ИБ сильнее грузил проц, и бэкап для него
уперся не в диск, а в проц. И если бы процессор был получше,
то по дискам была бы разница как для ФБ.
А у ФБ лучше менеджер памяти, и он проц меньше грузит, зато
больше грузит диски.
Впрочем, это и видно на графиках дальше.
Ежели нужно и кому то интересно можем выложить логи и иную необходимую
информацию.
HP ProLiant DL580 G5
4 6-Core Processors Intel Xeon X7460 (2.67 GHz, 16MB cache)
16GB memory
HP Smart Array P800 Controller
300 GB 15K SAS Drive
почем в сумме?
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
