Всем привет, надо было перенести реплики на другой сервер, на

старом сервере стоит версия Tarantool 2.2.2-0-g0a577ff30, на новом сервере Tarantool 2.2.3-0-gb9c4c7c04, конфиги все перенес со старого сервера на новый, в конфигах прописано memtx_memory = 10000000000; # 10 gb, но когда начинаю стартовать реплики на новом сервере, то они съедают всю память и похоже что memtx_memory никак их не ограничивает
вот пример как память съедается
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
769350 taranto+ 20 0 57.9g 51.0g 15492 R 100.0 81.7 5:15.52 tarantool

что это может быть?

пс. на старом сервере все ок, больше 10 гиг не использует
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27178 taranto+ 20 0 10.747g 3.233g 5364 R 61.1 10.4 27816:48 tarantool
13664 taranto+ 20 0 10.705g 2.890g 5420 S 77.8 9.3 27703:24 tarantool

Похоже на https://github.com/tarantool/tarantool/issues/5536

Если это та проблема, то пока нет. Скоро фикс выпустим, но он будет в 2.6.3, 2.7.2 и дальше Реплики память выжирают на стадии sync? Можно вывод box.info.replication с них?

на стадии синк и даже после, когда синхронизировались, вывод сейчас попробую сделать

сейчас вообще реплика отваливается по таймауту 2021-01-22 16:04:47.650 [802522] main/110/applier/user@51. I> will retry every 60.00 second 2021-01-22 16:05:47.736 [802522] main/110/applier/user@51. I> authenticated 2021-01-22 16:05:47.758 [802522] main/110/applier/user@51. I> subscribed 2021-01-22 16:05:47.758 [802522] main/110/applier/user@51. I> remote vclock {1: 160336292617, 2: 66085717162} local vclock {1: 160335568147, 2: 66085717162} 2021-01-22 16:05:53.556 [802522] main/123/applierw/user@51 C> leaving orphan mode 2021-01-22 16:05:57.578 [802522] main/110/applier/user@51. I> can't read row 2021-01-22 16:05:57.578 [802522] main/110/applier/user@51. xrow.c:1079 E> ER_SYSTEM: timed out а на мастере coio.cc:340 !> SystemError timed out: Operation timed out relay/repl:6358/101/main C> exiting the relay loop ну и память PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 802522 taranto+ 20 0 23.3g 14.3g 15988 S 0.0 22.8 6:20.25 tarantool

Нагрузка на мастер большая?

средняя load average: 15.69, 16.59, 16.98 CPU(s): 32 On-line CPU(s) list: 0-31 Thread(s) per core: 2 Core(s) per socket: 16 Socket(s): 1 NUMA node(s): 4 Vendor ID: AuthenticAMD CPU family: 23 Model: 1 Model name: AMD EPYC 7371 16-Core Processor

А в rps приблизительно сколько?

это данные с сервера покажите box.stat(), box.stat.net()

box.stat() --- - DELETE: total: 1524230626 rps: 121 SELECT: total: 20614662449 rps: 1876 INSERT: total: 1157425840 rps: 122 EVAL: total: 3876155559 rps: 384 CALL: total: 5874396 rps: 0 ERROR: total: 30782 rps: 0 REPLACE: total: 8785612 rps: 0 UPSERT: total: 5624836009 rps: 458 AUTH: total: 3671682247 rps: 345 EXECUTE: total: 0 rps: 0 UPDATE: total: 120954356229 rps: 12044 box.stat.net() --- - SENT: total: 1507691239696 rps: 146472 CONNECTIONS: current: 54 rps: 344 total: 3671723394 REQUESTS: current: 16 rps: 1078 total: 11917123492 RECEIVED: total: 1393330150176 rps: 123163

Итого: есть ~ 12-14k операций в секунду в WAL и есть 10 гиг арены. Правильно я понимаю, получается что джоин реплики не имеет сходимости во времени?

Это не джоин. Это синк уже

Я хочу понять: чистый ребутстрап поможет запустить реплику? Ну и на такой нагрузке непонятно, с чего ей не успевать

Должно помочь подключить реплику когда вообще нагрузки нет. Ребутстрап кажется не поможет. И дело не только в нагрузке, а ещё в количестве данных. Пока мастер отсылает снапшот, он успевает накопить данные в икслоге, и их отправляет с гораздо большим рпс

Ну, отключение нагрузки, как мы понимаем, это не вариант.

@sergepetrenko remote vclock {1: 160478605221, 2: 66085717162} local vclock {1: 160476416837, 2: 66085717162} — дельта 2M транзакций. спустя 17 секунд мы видим replica set sync complete (т.е. реплика догналась со вполне нормальной скоростью 128krps) и спустя 4 секунды applier отстрелило по таймауту. это не очень похоже на проблему oom при асинхронном апплаере.

Если вам не сложно, давайте попробуем немного подкрутить таймауты. попробуйте тот-же синк реплики, но с увеличенным replication_connect_timeout например поставить replication_connect_timeout = 60 (вместо дефолтных 30) и replication_timeout = 3 вместо дефолтного 1

все равно отваливается 2021-01-22 19:48:35.456 [2140313] main/102/app I> ready to accept requests 2021-01-22 19:48:35.456 [2140313] main/102/app I> synchronizing with 1 replicas 2021-01-22 19:48:35.475 [2140313] main/110/applier/user@51. I> subscribed 2021-01-22 19:48:35.475 [2140313] main/110/applier/user@51. I> remote vclock {1: 160500452415, 2: 66085717162} local vclock {1: 160499135976, 2: 66085717162} 2021-01-22 19:48:45.265 [2140313] main/111/applierw/user@51 C> leaving orphan mode 2021-01-22 19:48:45.265 [2140313] main/102/app I> replica set sync complete 2021-01-22 19:48:45.265 [2140313] main/102/app C> leaving orphan mode 2021-01-22 19:48:45.265 [2140313] main/102/app I> set 'checkpoint_interval' configuration option to 0 2021-01-22 19:48:45.265 [2140313] main/102/app I> set 'replication_connect_timeout' configuration option to 60 2021-01-22 19:48:45.265 [2140313] main/102/app I> set 'replication_timeout' configuration option to 60 2021-01-22 19:48:45.265 [2140313] main/102/app I> set 'memtx_memory' configuration option to 10000000000 2021-01-22 19:48:45.265 [2140313] main/102/app I> set 'net_msg_max' configuration option to 4000 2021-01-22 19:48:45.265 [2140313] main/102/app I> set 'listen' configuration option to "3311" 2021-01-22 19:48:45.265 [2140313] main/102/app I> set 'replication_connect_quorum' configuration option to 1 2021-01-22 19:48:45.265 [2140313] main/102/app I> set 'read_only' configuration option to true 2021-01-22 19:48:45.265 [2140313] main/102/app I> set 'readahead' configuration option to 32640 2021-01-22 19:48:45.265 [2140313] main/102/app I> set 'replication' configuration option to ["user@ip_master:port"] 2021-01-22 19:48:45.265 [2140313] main C> entering the event loop 2021-01-22 19:48:49.285 [2140313] main/110/applier/user@51. I> can't read row 2021-01-22 19:48:49.285 [2140313] main/110/applier/user@51. xrow.c:1079 E> ER_SYSTEM: timed out 2021-01-22 19:48:49.285 [2140313] main/110/applier/user@51. I> will retry every 60.00 second

хм... у меня была надежда на низкий replication_timeout...

а можете дать момент старта подключения реплики? хочу понять, с чем может биться момент 2021-01-22 19:48:49.285 [2140313] main/110/applier/user@51. xrow.c:1079 E> ER_SYSTEM: timed out от чего то же он отсчитывается

немного не понял, что надо показать?

если это на разных серверах - посмотрите чтобы часы были синхронизированы

поставил такую же таймзону как и на мастере, но не помогло

Костя говорил не про таймзону, а про синхронизацию времени (ntp) но судя по всему тут дело точно не в этом