Это пользователь root
для MySQL. Это не имеет ничего общего с пользователем Linux root
. Как и его аналог в Linux, это имя учетной записи суперпользователя в MySQL.
Вы не должны использовать root
в качестве пользователя MySQL для своей базы данных Wordpress, это большой риск для безопасности. Создайте для него пользователя MySQL wp
(или что-то еще), а затем предоставьте ему доступ только к базе данных wordpress
.
Host: Linux Mint 18 Cinnamon 64-bit (полностью обновлено); версия ядра 4.4.0-47-generic
Гость: Windows 8.1 Pro 64-bit (полностью обновлена)
Процессор: Intel Core i7-4700HQ, (6MB кэш, 4 физических ядра, или 8 с использованием Hyper-Threading), CPU Benchmark
VirtualBox: Версия 5.1.10 r112026 (Qt5.5.1)
Гостевые дополнения: Установлено и обновлено
Benchmark Tool #1: WinRAR версии 5.40 final 64-bit
Benchmark Tool #2: VeraCrypt version 1.19 final 64-bit
В обоих случаях я ждал после загрузки, пока CPU, RAM, дисковый накопитель не достигнут стабильного состояния, близкого к нулю.
4 ядра => 7.5 минут (меньшее время лучше)
WinRAR с 4 включенными ядрами, 1.5GiB обрабатывается за 7.5 минут.
8 ядер => 4.5 минуты (меньшее время лучше)
WinRAR с 8 включенными ядрами, 1.5GiB обрабатывается за 4.5 минуты.
4 ядра => скорость 2.6 GiB/s (выше скорость лучше)
VeraCrypt с 4 ядрами, HW-ускоренный AES (AES-NI) скорость 2.6 GiB/s.
8 ядер => скорость 3.9 GiB/s (выше скорость лучше)
VeraCrypt с 8 включенными ядрами, HW-ускоренный AES (AES-NI) скорость 3.9 GiB/s.
Я мог бы провести столько тестов, сколько необходимо. Но я подумал, что если эти два, один из которых довольно сложный тест на сжатие, а второй - набор довольно сложных тестов на шифрование, то какой в этом смысл.
Оба бенчмарка показывают заметную разницу. Я не вижу причин полагать, что их результаты неточны, поскольку я следовал довольно строгой подготовке и методу, кроме того, эти тесты проводились в оперативной памяти, чтобы исключить узкое место ввода-вывода. С моей точки зрения, предупреждение, упомянутое в вопросе, может быть применимо к некоторым условиям, но, конечно, не ко всем. Поделившись с вами этими довольно примечательными результатами, я уверен, что вы согласитесь со мной, что это предупреждение, вероятно, не стоит воспринимать так серьезно на современных процессорах с Hyper-Threading и последней версией VirtualBox. Одно могу сказать точно: Не верьте мне на слово и проверьте это в собственных условиях, прежде чем решите применить эту настройку на постоянной основе.
Хост + Гость: Linux Mint 19.2 "Tina" - Cinnamon (64-bit); оба с ядром: 5.3.0-24-generic
.
Processor: Intel® Core™ i7-7700HQ; 6 МБ кэша, до 3,80 ГГц, 4 физических ядра или 8 с использованием Hyper-Threading, сравнение CPU Benchmark
VirtualBox: Версия 6.1.0 r135406 (Qt5.9.5)
Гостевые дополнения: Установлено и обновлено
Benchmark Tool: VeraCrypt version 1.24 Hotfix1 64-bit final (web page, direct deb download link)
То же, что и предыдущий бенчмарк.
⟶ скорость 4.8 GiB/s (выше скорость - лучше)
⟶ скорость 7. 2 GiB/s (более высокая скорость лучше)
Замечательный 50% прирост производительности с Hyper-Threading включен, но только с AES, к сожалению, мне придется провести более комплексное тестирование. Я вернусь через несколько дней с результатами.
Как разработчик ОС полностью согласен с результатом измерений. Количество чуши, созданной в другом месте по этому вопросу, невероятно.
См. количество логических ядер как количество параллельных потоков/процессов, которые могут выполняться аппаратным обеспечением. Это достигается путем дублирования, например. регистры и указатели инструкций ядра ЦП. Теперь ядро ЦП само решает, какой поток (указатель инструкций) использовать. Он решит использовать другой поток, поскольку инструкция текущего потока недоступна в кеше и должна быть извлечена, например, из памяти или кэш-памяти L3. Этот механизм создаст потенциальное улучшение на 10-30% количества инструкций/секунд или производительности процессора.
Если вы запускаете одно приложение с одним потоком, вы не сможете воспользоваться этим преимуществом, но если вы запустите два приложения с высокой нагрузкой, например, на старый HT Pentium, вы сможете воспользоваться преимуществами. То же самое верно и для приложений, которые имеют более одного потока. Моя система Linux имеет 200 потоков, поэтому всегда присутствуют некоторые преимущества, зависящие от фактической нагрузки. Все эти замечания применимы без виртуализации.
Virtualbox ограничивает только количество потоков, которые могут выполняться параллельно для каждой виртуальной машины (ВМ), но планировщик хост-процессов изменит логический(е) процессор(ы) и, следовательно, физический(е) процессор(ы), на которых выполняются процессы ВМ. динамически. Если вы запускаете приложения с высокой нагрузкой на виртуальной машине, дополнительные логические ядра дадут вам такое же преимущество в 10%-30%. Нагрузкой может быть одно многопоточное приложение или набор различных приложений.
В современных системах с VT-x или AMD-V нет снижения производительности при максимальном количестве логических ядер, поскольку также нет заметного снижения производительности при одновременном запуске большего количества виртуальных машин. Ваш предел — это производительность чипа ЦП, поэтому вы не можете отображать видео на 3 ВМ одновременно, не замедляя работу каждой ВМ, поскольку они должны использовать один и тот же физический ЦП.
Ваша хост-система может перестать отвечать на запросы, если вы рендерите видео на виртуальной машине со всеми присутствующими логическими ядрами, но у вас будет почти такая же проблема, если вы запустите это приложение рендеринга на своем хосте. По крайней мере, в VM у вас есть выбор, и вы можете решить его, ограничив максимальную загрузку процессора до 80%-90% или уменьшив количество ядер по этой причине.
Mis mejores dos centavos son nunca usar todos los núcleos/subprocesos, solo deje uno o dos para el host.
Entonces, en su caso, proporcione al invitado seis núcleos, nunca un octavo núcleo (porque solo tiene 8 subprocesos en el host ).
Si el número de subprocesos disponibles (que no debe confundirse con los núcleos )en el host es:
Para más de dos hilos tiendo a usar esta fórmula:
Mi experiencia me dice que es mucho más sencillo y menos riesgoso no sobrepasar el límite de dicha fórmula.
Advertencia :No está permitido cambiar la cantidad de núcleos invitados mientras se ejecuta el invitado, pero sí se permite reducir el uso de la CPU del 100 % al 75 % o también al 50 %; no menos invitados pueden fallar.
Entonces, a veces tiendo a dar a dos invitados 6 seis núcleos en un host de 8 subprocesos (el número de la fórmula como si fuera solo un invitado en lugar de dos invitados ),pero limitándolos al 50% de la velocidad de la CPU (para que ambos invitados puedan usar la mitad del tiempo de la CPU ), pero solo cuando sé que los invitados ejecutarán aplicaciones que tienen una proporción de paralelo mayor que uno, como con comparación de imágenes/juntas, etc.