Как измерить производительность виртуального сервера?
Я понял вопрос, я использовал ssh-add -L, чтобы перечислить используемые открытые ключи, я узнал, что он отличается от того, который был в id_rsa.pub, я думаю, что когда-то я случайно заменил исходный файл открытого ключа другим , так что теперь он работает нормально
2 ответа
Ну, так как никто не хочет отвечать ...:)
Поиск Synaptic для «скамейки» находит множество наборов тестов, способных тестировать различные аспекты машины. Единственный, о котором я слышал ранее, - phoronix-test-suite, который, я уверен, очень всеобъемлющий, хотя мой короткий охват внимания не позволил мне понять, как его использовать.
Затем я нашел UnixBench, который описан как
UnixBench - это оригинальный набор тестов BYTE UNIX, обновленный и пересмотренный многими людьми на протяжении многих лет. Цель UnixBench - предоставить базовый индикатор производительности Unix-подобной системы; ... Эти результаты теста затем сравниваются с оценками из базовой системы, чтобы получить значение индекса, которое, как правило, легче обрабатывать, чем исходные оценки. Обработаны многопроцессорные системы. ... Тесты сравнивают системы Unix, сравнивая их результаты с набором показателей, установленным при запуске кода в тестовой системе, которая является SPARCstation 20-61 (с рейтингом 10.0).UnixBench упоминается Linode как инструмент для тестирования производительности VM в UnixBench :
UnixBench - это оригинальный набор тестов BYTE UNIX, обновленный и пересмотренный многими людьми на протяжении многих лет.
Используя идентичные аппаратные средства, KVM Linodes намного быстрее по сравнению с Xen. Например, в нашем тестировании UnixBench KVM Linode набрал 3 раза лучше, чем Xen Linode.
wget https://github.com/kdlucas/byte-unixbench/archive/master.zip
unzip ./master.zip
cd ./byte-unixbench-master/UnixBench
./Run
Набор тестов НЕ находится в репозиториях Ubuntu, но тривиально загрузить и скомпилировать его: [!d12 ]
------------------------------------------------------------------------
Benchmark Run: Mon Oct 15 2012 23:55:22 - 00:23:16
4 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 12015218.4 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2214.8 MWIPS (10.1 s, 7 samples)
Execl Throughput 896.9 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 58968.3 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 14578.6 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 422068.2 KBps (30.0 s, 2 samples)
Pipe Throughput 70993.3 lps (10.0 s, 7 samples)
Pipe-based Context Switching 16001.5 lps (10.0 s, 7 samples)
Process Creation 1861.8 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 2525.5 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 737.8 lpm (60.1 s, 2 samples)
System Call Overhead 432496.2 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 12015218.4 1029.6
Double-Precision Whetstone 55.0 2214.8 402.7
Execl Throughput 43.0 896.9 208.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 58968.3 148.9
File Copy 256 bufsize 500 maxblocks 1655.0 14578.6 88.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 422068.2 727.7
Pipe Throughput 12440.0 70993.3 57.1
Pipe-based Context Switching 4000.0 16001.5 40.0
Process Creation 126.0 1861.8 147.8
Shell Scripts (1 concurrent) 42.4 2525.5 595.6
Shell Scripts (8 concurrent) 6.0 737.8 1229.7
System Call Overhead 15000.0 432496.2 288.3
========
System Benchmarks Index Score 249.7
------------------------------------------------------------------------
Benchmark Run: Tue Oct 16 2012 00:23:16 - 00:51:20
4 CPUs in system; running 4 parallel copies of tests
Dhrystone 2 using register variables 42619039.2 lps (10.0 s, 7 samples)
Double-Precision Whetstone 8274.0 MWIPS (10.4 s, 7 samples)
Execl Throughput 3398.5 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 68332.4 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 21462.9 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 718205.6 KBps (30.0 s, 2 samples)
Pipe Throughput 149713.5 lps (10.0 s, 7 samples)
Pipe-based Context Switching 61968.3 lps (10.0 s, 7 samples)
Process Creation 5321.7 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 5957.1 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 812.6 lpm (60.1 s, 2 samples)
System Call Overhead 1557391.5 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 42619039.2 3652.0
Double-Precision Whetstone 55.0 8274.0 1504.4
Execl Throughput 43.0 3398.5 790.4
File Copy 1024 bufsize 2000 maxblocks 3960.0 68332.4 172.6
File Copy 256 bufsize 500 maxblocks 1655.0 21462.9 129.7
File Copy 4096 bufsize 8000 maxblocks 5800.0 718205.6 1238.3
Pipe Throughput 12440.0 149713.5 120.3
Pipe-based Context Switching 4000.0 61968.3 154.9
Process Creation 126.0 5321.7 422.4
Shell Scripts (1 concurrent) 42.4 5957.1 1405.0
Shell Scripts (8 concurrent) 6.0 812.6 1354.3
System Call Overhead 15000.0 1557391.5 1038.3
========
System Benchmarks Index Score 592.5
Тесты требуют времени, чтобы закончить. Результат выглядит как
. Это означает, что у VPS есть оценка 249,7 для одной задачи и 592,5 для параллельной обработки.
Мой настольный компьютер, имея аналогичные или более низкие спецификации для физическая машина, на которой работает мой VPS, произвела оценку 1409,7 для одной задачи и 5156.3 для параллельной обработки. Именно этот показатель я искал.
wget freevps.us/downloads/bench.sh -O - -o /dev/null|bash
Еще одна важная метрика - скорость сети. Я нашел скрипт, который загружает тестовые файлы из разных мест и измеряет скорость загрузки. Сценарий можно запустить с помощью
(хотя, вероятно, было бы безопаснее загрузить скрипт и проверить его содержимое перед запуском)
# ioping . -c 10
4096 bytes from . (ext4 /dev/disk/...): request=1 time=16.4 ms
4096 bytes from . (ext4 /dev/disk/...): request=2 time=16.1 ms
...
-
1UnixBench теперь находится на Github: github.com/kdlucas/byte-unixbench – m0j0 25 September 2015 в 00:25
-
2@ m0j0: Я изменил ответ, чтобы подумать, что он размещен в GitHub сейчас, спасибо – Sergey 25 September 2015 в 00:33
Это может быть невозможно. Вы не предоставляете никаких подробностей, поэтому никто не может дать конкретные ответы. Но не все VPS - это виртуальное оборудование. У вас есть всевозможные решения, такие как Linux Containers (LXC), которые радикально отличаются от разбора виртуальной машины с определенными особенностями.
Единственным пунктом совместного использования оборудования является его повторное использование. В вашем случае, даже если вы используете виртуализованное оборудование, вы не можете быть уверены, что используете его только один. Если вам нужна информация об использовании оборудования, тогда вы должны получить совместно расположенный физический сервер.
-
1Ahh, я думаю, вы меня неправильно поняли - я не говорю о базовой физической машине. Я обновил свой вопрос. – Sergey 7 March 2012 в 10:57
-
2Да, но все же. Компьютер может отличаться от одного момента к другому, поэтому любое среднее значение бесполезно. В один момент он может иметь 16 ядер процессора и 32 ГБ оперативной памяти, а в другом - 1 ядро и 512 МБ ОЗУ. Среднее значение может быть крайне низким или лучше, чем теоретически возможно, в зависимости от того, когда вы вычисляете. Вы можете получить некоторые данные из «ps ax», «top», «iotop», и «время безотказной работы», но это не будет стоить многого. – Jo-Erlend Schinstad 7 March 2012 в 13:14
-
3Хорошо, пример: я gzip 1Gb-файл на моем нетбуке и измеряю время, необходимое для выполнения задачи. Затем я gzip тот же файл на моем рабочем столе - оказывается, мой рабочий стол делает это в 3 раза быстрее, чем нетбук, поэтому я даю им «рейтинг gzip». 100 и 300 соответственно. Затем я сжимаю один и тот же файл на VPS и нахожу, скажем, что во время теста он в 1,5 раза быстрее, чем нетбук, но все же в 2 раза медленнее, чем рабочий стол - так что это «коэффициент gzip». из 150. Я могу разработать что-то подобное себе, но, безусловно, измерение производительности - общая проблема – Sergey 7 March 2012 в 13:32
-
4Измерение производительности прекрасное, если вы знаете, какой компьютер вы измеряете. С VPS вы не обязательно это знаете. Это может быть перемещено между множеством совершенно разных компьютеров без вашего ведома, процессоры могут быть добавлены и удалены, добавлены и удалены ОЗУ и т. Д. Или другой VPS начинает использовать много CPU в течение 25 секунд, делая ваш VPS медленнее. Слишком много переменных. – Jo-Erlend Schinstad 7 March 2012 в 14:14
-
5Похоже, что может быть ниша для инструмента мониторинга производительности vps. – justingrif 7 March 2012 в 20:48