Несоответствие производительности Neo4j локально против облака

Question

Я столкнулся с разницей в производительности c между локальным экземпляром Neo4j, работающим на виртуальной машине, размещенной в VirtualBox, и практически идентичным экземпляром Neo4j, размещенным в Google Cloud (GCP). Задача включает выполнение простой загрузки из экземпляра Postgres, также расположенного в GCP. Вся загрузка занимает 1-2 минуты на экземпляре виртуальной машины, размещенной в VirtualBox, и 1-2 часа на экземпляре виртуальной машины GCP. Локальная установка оборудования - это 10-летний 8-ядерный рабочий стол 16 ГБ с VirtualBox 6.1.

. С VirtualBox и GCP я выполняю следующие похожие задачи:

1. предоставление 4-ядерный экземпляр Ubuntu 18 LTS объемом 8 ГБ

2. установить Neo4j Community Edition 4.0.2

3. с помощью wget для загрузки последней версии apo c и postgres jdb c jars в плагины dir

4. (только в GCP файл neo4j.conf изменен по умолчанию. Я раскомментирую "dbms.default_listen_address = 0.0.0.0 "линия, разрешающая нелокальные соединения. Также создано соответствующее правило межсетевого экрана GCP)

5. перезапустите службу neo4j

6. установите и запустите htop и iotop для мониторинг оборудования

7. вход в пустой экземпляр neo4j через консоль broswer

8. загрузить драйвер jdb c и выполнить оператор загрузки

Оператор загрузки использует apo c .periodi c .iterate для вызова apo c .Load.jdb c. Я изменил параметр "batchSize" в обеих средах от 100 до 10000, но видел только незначительные изменения в любой системе. Параметр «параллельный» имеет значение «ложь», поскольку значение «истина» вызывает ошибки блокировки.

При просмотре сетевых операций ввода-вывода обеим операциям требуется ~ 15-25 секунд, чтобы извлечь ~ 700 тыс. Строк (8 столбцов) из таблицы базы данных. , Наблюдая за процессором, оба поддерживают максимальное ядро ​​на уровне 100%, а другое - 0-100%. Наблюдая за памятью, ни одна из них не занимает больше 4 ГБ, а подкачка остается на 0. Изначально я использовал рекомендации по настройке из «neo4j-admin memre c», но, похоже, что они ничего существенно не изменили ни в использовании памяти, ни в общем времени выполнения. .

Просмотр диска, вот где есть различия. Но я думаю, что это симптомы, а не причина root: локальная виртуальная машина постоянно записывает 1-2 МБ / с в течение всего времени выполнения (1-2 минуты). Пакет виртуальных машин GCP записывает 300–400 КБ / с в течение 1 секунды каждые 20–30 секунд. Но я не думаю, что диски GCP работают медленно или проблема (я пробовал как со стандартным диском GCP, так и с их диском SSD). Если бы диски GCP были медленными, я бы ожидал увидеть постоянную активность записи и огромную очередь записи на диск. Кажется, когда что-то должно быть записано на диск, это делается быстро в GCP. Кажется, узким местом является то, что перед записью диска.

Все, что я могу себе представить, это то, что мои 10-летние ядра работают намного быстрее, чем текущий виртуальный процессор GCP, или что происходит какая-то куча памяти. Я не знаю много о java, за исключением того, что кучи важны и могут быть привередливыми.

Answer 1

У вас есть одно и то же: схема на обеих системах? Если вам не хватает критического индекса, используемого в вашем запросе LOAD, который может легко объяснить различия, которые вы видите.

Например, если вы используете MATCH или MERGE для узла по определенному свойству, разница между быстрым поиском узла по индексу или сканированием меток всех узлов из этой метки, проверяя каждый из них, чтобы увидеть, существует ли узел или это правильный узел. Также следует понимать, что этот процесс повторяется для каждой отдельной строки, поэтому в худшем случае это не сканирование одной метки, а n раз.