My k6 crashed after 14 h

Grafana k6
1

k6 javascript target 60, duration 48hourse , crashed at about 14hours

image
image1133×842 50.7 KB

2

I deleted your other 2 threads, please do not post multiple topics with the same question.

It’s quite likely that your machine ran out of free memory and that is why k6 crashed after 14 hours. Can you share some more details about your script, which k6 version and OS you are using, etc?

3

sorry .
my k6 version – k6 v0.37.0 (2022-03-15T09:43:55+0000/67657f4, go1.17.7, linux/amd64)
my centos version – Linux version 4.19.90-17.ky10.x86_64 (YHKYLIN-OS@localhost.localdomain) (gcc version 7.3.0 (GCC)) #1 SMP Sun Jun 28 15:41:49 CST 2020

image
image1048×769 13.2 KB

4

@1766 do you use a metric output? And if yes, then which one?
Any other cli arguments?

5

sorry, i dont understand , like utf-8?

6

No, as in an output that k6 will be pushing metrics to.

My other question about cli arguments is likely more important as it will include this info as well :wink:

7

sorry ,i cant offer more infomations :face_with_hand_over_mouth:

8

Well then I am not certain we can help you all that much :person_shrugging:

I would recommend updating k6 as the later versions are less likely to have bugs in general and there have been some fixes in the area around metrics handling.

The only thing I can glimpse from this traceback is that k6 coulndn’t push a metric through the system for over 14m. This isn’t event to a metric/result output, but internally. This to me means that you either have hit some bug or the metrics system was severely backlogged. I also can’t remember ever seeing that happen.

I can’t even imagine how k6 would still be running if it can’t push some samples after 14m. My guess is that you are running on a machine with a lot of memory which let it stay in that state a lot longer … or again there is a bug.

Without any info on how you run k6 and what the RPS is I can’t even guess if that is to be expected.

Other notes:

  1. the current optiosn you have provided mean that you will start 1 VU and will run with 60 after 48h . k6 will linearly increase the VUs over that period. So at 14h you will have something like 17-18 VUs. I guess you want to run with 60 VUs for 48h? In this case you should add vus: 60 next to stages.
  2. I would recommend arrival rate executors for more stable rate
  3. I would move the definition of payload, url and params to ouside the loop given that they do not change.
  4. I would also drop the 200 status check as that is handled with expected_response. You can specifically set it to only expect 200 instead of the default 2xx and 3xx.
  5. depending on the size of the response I would recommend doing r.json('code') === 1 which will skip on parsing and returning as much data

This should optimized the memory usage somewhat but I am still not certain any of this will help if k6 is slowed down by a result output that just doesn’t handle the amount of samples that k6 is emitting

9

thanks ,I will take your advice ,updating k6 and update javascript :smiley: