Gtling tool throws GC Верхний предел превышен

Question

Я пытаюсь запустить тест нагрузки, который использует метод подачи, который находится в инструменте Gatling. В настоящее время, когда мы используем файл, размером около 3.5gb который имеет 600000 записей, Гатлинга терпит неудачу за исключением, как показано ниже: Моделирование LoadTestSimulation началось ...

Исключение в потоке «основной» java.lang.OutOfMemoryError : предел ГХ накладных расходов превысил на java.util.Arrays.copyOf (Arrays.java:2367) на java.lang.AbstractStringBuilder.expandCapacity (AbstractStringBuilder.java:130) в java.lang.AbstractStringBuilder.ensureCapacityInternal (AbstractStringBuilder.java : 114) at java.lang.AbstractStringBuilder.append (AbstractStringBuilder.java:535) at java.lang.StringBuffer.append (StringBuffer.java:322) at java.io.BufferedReader.readLine (BufferedReader.java:351) at java.io.BufferedReader.readLine (BufferedReader.java:382) at scala.io.BufferedSource $ BufferedLineIterator.hasNext (BufferedSource.scala: 72) at scala.collection.Iterator $$ anon $ 11.hasNext (Iterator.scala: 369) at scala.collection.Iterator $$ anon $ 11.hasNext (Iterator.scala: 369) at scala.collection.Iterator $ class. foreach (Iterator.scala: 742) at scala.collection.AbstractIterator.foreach (Iterator.scala: 1194) at scala.collection.generic.Growable $ class. $ plus $ plus $ eq (Growable.scala: 59) at scala.collection.immutable.VectorBuilder. $ plus $ plus $ eq (Vector.scala: 732) at scala.collection.immutable.VectorBuilder. $ plus $ plus $ eq (Vector.scala: 708) at scala.collection.TraversableOnce $ class.to (TraversableOnce.scala: 308) at scala.collection.AbstractIterator.to (Iterator.scala: 1194) at scala.collection.TraversableOnce $ class.toVector (TraversableOnce.scala: 304) at scala.collection.AbstractIterator.toVector (Iterator.scala: 1194) at io.gatling.core.feeder.SeparatedValuesParser $$ anonfun $ parse $ 1.apply (SeparatedValuesParser.scala: 34) at io.gatling. core.feeder.SeparatedValuesParser $$ anonfun $ parse $ 1.apply (SeparatedValuesParser.scala: 33) at io.gatling.core.util.IO $ .withSource (IO.scala: 152) at io.gatling.core.feeder .SeparatedValuesParser $ .parse (SeparatedValuesParser.scala: 33) at io.gatling.core.feeder.FeederSupport $$ anonfun $ separatedValues ​​$ 1.apply (FeederSupp ort.scala: 38) at io.gatling.core.feeder.FeederSupport $$ anonfun $ separatedValues ​​$ 1.apply (FeederSupport.scala: 38) в io.gatling.core.feeder.FeederSupport $ class.feederBuilder (FeederSupport. scala: 46) at io.gatling.core.Predef $ .feederBuilder (Predef.scala: 32) at io.gatling.core.feeder.FeederSupport $ class.separatedValues ​​(FeederSupport.scala: 38) at io.gatling .core.Predef $ .separatedValues ​​(Predef.scala: 32) в io.gatling.core.feeder.FeederSupport $ class.separatedValues ​​(FeederSupport.scala: 35) в io.gatling.core.Predef $ .separatedValues ​​(Predef .scala: 32) at io.gatling.core.feeder.FeederSupport $ class.tsv (FeederSupport.scala: 32) : gatling FAILED

Мы используем задачу gatling градации, которая использует эти параметры - -PjvmArgs = -Dbroker = brokerhost: 9092 -Dtopic = -Dusers = 100 -Dduration_in_mins = 2 -Dinput_file_name = -Psim = "LoadTestSimulation".

вал SCN = сценарий ("Demo") .feed (TSV (inputFileName, правда) .circular) .exec (Кафка ("запрос") .sendString, String)

нАлАдкА ( SCN .inject (constantUsersPerSec (пользователи.toDouble) в течение (duration.toInt минут)) //scn.inject(rampUsers(500) в течение (200 секунд)) .protocols (kafkaConf)) }

Любые предложения или советы, мы должны разделить файл для нескольких файлов и запускать вместо передачи такого большого файла, Будет ли этот файл загружаться в память сразу?

Answer 1

Вы используете TSV, то есть отдельный разделитель файлов. Это то, что официальная документация говорит:

Those built-ins returns RecordSeqFeederBuilder instances, meaning that the whole file is loaded in memory and parsed, so the resulting feeders doesn’t read on disk during the simulation run.

или лучше:

Loading feeder files in memory uses a lot of heap, expect a 5-to-10-times ratio with the file size. This is due to JVM’s internal UTF-16 char encoding and object headers overhead. If memory is an issue for you, you might want to read from the filesystem on the fly and build your own Feeder.

Для получения дополнительной информации см CSV Feeders.

Что вы «можете» сделать, чтобы попытаться увеличить объем памяти достаточно, чтобы позволить JVM и GC работать на такой «огромный» файл в памяти, который я думаю, не будет работать из-за причины вашего исключения (см больше here)

Так что, я думаю, ваш единственный вариант - написать собственный фидер, который читает данные из файла на лету.