Начинаем с установки на систему - Ubuntu-15.10 - десктоп эдишн 64.
Устанавливаем все обновления.
Измеряем начальные настройки postgresql-9.4
Коротко о железе - диск hdd, 8gb ram, i5-750 цпу.
Измерять будет с удаленного ноутбука по сети.
shared_buffers = 8MB
work_mem = 4MB
Инициализируем БД
pgbench -i -s 10 -h 192.168.1.103 -U postgres tmp
Размер базы 166мб
Тестим через wifi
pgbench -U postgres -T 10 -h 192.168.1.103 tmp
scaling factor: 10
query mode: simple
number of clients: 1
number of threads: 1
duration: 10 s
number of transactions actually processed: 555
latency average: 18.018 ms
Итог: 53-55 tps
Тестим локально:
112 tps
Тестим через 10mb ethernet
110tps
Вывод - соединение с сервером решает. Надо тестить через эзернет.
Если будем создавать новый коннект на каждое соединение - то будет всё плохо
tps = 39.143242 (including connections establishing)
tps = 72.343396 (excluding connections establishing)
Поставим число клиентов в 2 -c 2
tps = 115.960384 (including connections establishing)
tps = 116.221777 (excluding connections establishing)
Переходим на T 20
Если клиентов 8, то
transaction type: TPC-B (sort of)
scaling factor: 10
query mode: simple
number of clients: 8
number of threads: 1
duration: 20 s
number of transactions actually processed: 4877
latency average: 32.807 ms
tps = 243.586452 (including connections establishing)
tps = 244.582132 (excluding connections establishing)
При 16 коннектах 300-310 tps. Локально 400
При 32 коннектах 360.
pgbench -c 64 -U postgres -T 20 -h 192.168.1.103 tmp
tps = 365.203169 (including connections establishing)
tps = 377.551772 (excluding connections establishing)
Много соединений и процессов. Загружаются все ядра
Финальный длинный тест
pgbench -c 100 -U postgres -T 60 -h 192.168.1.103 tmp
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 10
query mode: simple
number of clients: 100
number of threads: 1
duration: 60 s
number of transactions actually processed: 22175
latency average: 270.575 ms
tps = 357.247713 (including connections establishing)
tps = 363.024830 (excluding connections establishing)
Бывает, разгоняется до 400.
При этом странно, что сеть держится непостоянно - идёт ровно и сбрасывается.
Пока на этих цифрах можно остановиться
Вообще есть теоритеческий предел. Один клиент может при обороте диска 7200 rpm сделать... 7200/60 = 120 оборотов диска в секунду
Т.к. каждый инсёрт сопровождается сбросом то в самых идеальных условиях максимум, что может показать система - это 120 tps.
Если много клиентов одновременно пишут, то обращение к диску может содержать сброс нескольких транзакций и tps вырастет. Что и было показано выше. Вот почему ssd значительно повышает tps вставок.
Устанавливаем все обновления.
Измеряем начальные настройки postgresql-9.4
Коротко о железе - диск hdd, 8gb ram, i5-750 цпу.
Измерять будет с удаленного ноутбука по сети.
shared_buffers = 8MB
work_mem = 4MB
Инициализируем БД
pgbench -i -s 10 -h 192.168.1.103 -U postgres tmp
Размер базы 166мб
Тестим через wifi
pgbench -U postgres -T 10 -h 192.168.1.103 tmp
scaling factor: 10
query mode: simple
number of clients: 1
number of threads: 1
duration: 10 s
number of transactions actually processed: 555
latency average: 18.018 ms
Итог: 53-55 tps
Тестим локально:
112 tps
Тестим через 10mb ethernet
110tps
Вывод - соединение с сервером решает. Надо тестить через эзернет.
Если будем создавать новый коннект на каждое соединение - то будет всё плохо
tps = 39.143242 (including connections establishing)
tps = 72.343396 (excluding connections establishing)
Поставим число клиентов в 2 -c 2
tps = 115.960384 (including connections establishing)
tps = 116.221777 (excluding connections establishing)
Переходим на T 20
Если клиентов 8, то
transaction type: TPC-B (sort of)
scaling factor: 10
query mode: simple
number of clients: 8
number of threads: 1
duration: 20 s
number of transactions actually processed: 4877
latency average: 32.807 ms
tps = 243.586452 (including connections establishing)
tps = 244.582132 (excluding connections establishing)
При 16 коннектах 300-310 tps. Локально 400
При 32 коннектах 360.
pgbench -c 64 -U postgres -T 20 -h 192.168.1.103 tmp
tps = 365.203169 (including connections establishing)
tps = 377.551772 (excluding connections establishing)
Много соединений и процессов. Загружаются все ядра
Финальный длинный тест
pgbench -c 100 -U postgres -T 60 -h 192.168.1.103 tmp
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 10
query mode: simple
number of clients: 100
number of threads: 1
duration: 60 s
number of transactions actually processed: 22175
latency average: 270.575 ms
tps = 357.247713 (including connections establishing)
tps = 363.024830 (excluding connections establishing)
Бывает, разгоняется до 400.
При этом странно, что сеть держится непостоянно - идёт ровно и сбрасывается.
Пока на этих цифрах можно остановиться
Вообще есть теоритеческий предел. Один клиент может при обороте диска 7200 rpm сделать... 7200/60 = 120 оборотов диска в секунду
Т.к. каждый инсёрт сопровождается сбросом то в самых идеальных условиях максимум, что может показать система - это 120 tps.
Если много клиентов одновременно пишут, то обращение к диску может содержать сброс нескольких транзакций и tps вырастет. Что и было показано выше. Вот почему ssd значительно повышает tps вставок.
Комментариев нет:
Отправить комментарий