MySQL вставляет причину, высокий диск i/o ожидает?
Неважно я получил функцию топологии в работе NMap. Я отправляю это как ответ в случае, если кто-то еще приезжает, ища тот же вопрос (также, потому что я не могу найти кнопку комментария). Просто Google nmap, или переходят к insecure.org.
@Izzy, ya, это действительно кажется тем путем. Я не знаю, почему, Отказ сервера действовал действительно странный, поскольку я пытался создать новую учетную запись на SF при обеспечении, что это связалось автоматически с моими очень используемыми учетными записями на Переполнении стека и SuperUser.
@mfinni, да, я не на самом деле системный администратор и всегда смущался различием между различными сетевыми устройствами. Я только сказал, что переключатель, потому что, когда я выполнил сканирование NMap в своей школьной сети, он показал весь трафик другим компьютерам, проходящим через один IP, и маркировал его посредством обнаружения сервиса/версии как Коммутатор Cisco. Хорошо на самом деле теперь, когда я думаю об этом, в то время как это маркировало устройство как переключатель, упомянутая ОС была маршрутизатором Cisco.
@joeqwerty, я знал, что должно было быть некоторое программное обеспечение, которое делает это, которое является, почему я обратился за помощью к нахождению такого приложения на Отказе сервера. "Мне нужно программное обеспечение, которое может автоматически генерировать карту топологии сети".
To answer it simply, yes.
The main indicator is the 53.2% wait time on the CPU. If your I/O wait percentage is greater than (1/# of CPU cores) then your CPUs are waiting a significant amount of time for the disk subsystem to catch up.
Inserts create disk write I/O, and that's generally the worst kind for virtual disks with a hard disk drive subsystem. HDDs are notoriously slower at writing than reading. This gap is lessened with SSDs, but write time is still slower than read time. Thus, any write operations are going to create more of a negative impact than read operations would.
Also, when you mix a large database and/or database that is under heavy load, with a disk sybsystem that's not designed for heavy I/O and already experiencing a large amount of I/O (like the disk sub-system of a VM), it multiplies the issue and creates major disk I/O issues.
Short of moving the server to a dedicated box with a disk sub-system that's optimized for SQL (which would be your long-term solution), your best bet is to take off any unnecessary load from the VM (like a web server), and just run the bare bones and SQL on it. Also, make sure you are tuning your indices and queries, and try and run the majority of the insert queries in off-peak hours, if possible.
Yes you are correct, you've got a disk I/O problem. BTW, why are you using innodb_flush_log_at_trx_commit=1? It does not work well in heavy load environments, using innodb_flush_log_at_trx_commit=2 is recommended. But I don't think it will help you because you have large inserts so I assume transaction rate is not too high (not hundreds per second). So you should consider improving your disk subsystem by adding more spindles somehow.
Чтобы быть противником, я вынужден не согласиться с некоторым анализом. Прежде всего, я думаю, что время iowait может ввести в заблуждение. Все, что он на самом деле говорит, это то, что пока процессор свободен, больше ничего не происходит. Другими словами, низкое значение iowait не означает, что диск не занят или система не ждет, это просто означает, что у него есть дела поважнее, чем бездельничать, вертя пальцами руки, ожидая завершения io.
Лично я считаю, что время ожидания и обслуживания в выводе iostat намного более информативно, хотя я не являюсь поклонником формата вывода, так как мне его гораздо труднее читать, чем вывод collectl. В любом случае время ожидания в этом выводе составляет всего порядка 20-40 мс, что на самом деле не так уж и плохо.
-mark