G1 GC processes references too slow - performance
So, we're using G1 GC. and 18GB heap. Young generation size is about 3,5G. And heap maximum usage is about 12G. And memory is full of short-living objects.
Also, maybe it's important that Couchbase instance is running on the same node near the JVM. It takes all iops often when it's persisting changes on hdd, but there are enough free cpu time and memory.
Enabled JVM options:
-Xmx18g -Xms18g -XX:MaxPermSize=512M -XX:+UseG1GC -XX:+DisableExplicitGC -XX:+ParallelRefProcEnabled
My sad problem is young generation GC pauses. Long pause GC log usually looks like:
2013-07-10T15:06:25.963+0400: 9122,066: [GC pause (young)
Desired survivor size 243269632 bytes, new threshold 5 (max 15)
- age 1: 69789280 bytes, 69789280 total
- age 2: 58618240 bytes, 128407520 total
- age 3: 54519720 bytes, 182927240 total
- age 4: 51592728 bytes, 234519968 total
- age 5: 45186520 bytes, 279706488 total
9122,066: [G1Ergonomics (CSet Construction) start choosing CSet, predicted base time: 174,16 ms, remaining time: 25,84 ms, target pause time: 200,00 ms]
9122,066: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 426 regions, survivors: 34 regions, predicted young region time: 164,97 ms]
9122,066: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 426 regions, survivors: 34 regions, old: 0 regions, predicted pause time: 339,13 ms, target pause time: 200,00 ms]
9122,259: [SoftReference, 0 refs, 0,0063780 secs]9124,575: [WeakReference, 4 refs, 0,0031600 secs]9124,578: [FinalReference, 1640 refs, 0,0033730 secs]9124,581: [PhantomReference, 145 refs, 0,0032080 secs]9124,5
85: [JNI Weak Reference, 0,0000810 secs], 2,53669600 secs]
[Parallel Time: 190,5 ms]
[GC Worker Start (ms): 9122066,6 9122066,7 9122066,7 9122066,7 9122066,8 9122066,9 9122066,9 9122066,9 9122066,9 9122067,0 9122067,0 9122067,1 9122067,1 9122067,1 9122067,1 9122067,2 91220
67,2 9122067,3
Avg: 9122067,0, Min: 9122066,6, Max: 9122067,3, Diff: 0,7]
[Ext Root Scanning (ms): 4,7 6,0 4,8 4,5 4,2 4,3 4,2 4,3 4,6 3,4 13,5 5,2 4,2 5,6 4,2 4,1 4,3 4,0
Avg: 5,0, Min: 3,4, Max: 13,5, Diff: 10,1]
[Update RS (ms): 20,9 19,6 21,1 21,3 21,2 21,2 21,3 21,2 21,7 21,5 12,1 20,2 21,1 19,4 21,0 21,1 20,7 21,2
Avg: 20,4, Min: 12,1, Max: 21,7, Diff: 9,6]
[Processed Buffers : 27 23 25 29 31 22 25 34 28 14 36 23 24 22 28 24 25 24
Sum: 464, Avg: 25, Min: 14, Max: 36, Diff: 22]
[Scan RS (ms): 9,0 9,2 8,7 8,8 9,1 9,1 8,9 9,1 8,3 9,2 9,0 9,1 9,2 9,2 9,1 9,0 9,0 9,1
Avg: 9,0, Min: 8,3, Max: 9,2, Diff: 1,0]
[Object Copy (ms): 145,1 145,0 145,2 145,1 145,1 144,9 145,1 144,9 144,9 145,4 144,8 144,8 144,8 145,0 145,0 145,1 145,2 144,9
Avg: 145,0, Min: 144,8, Max: 145,4, Diff: 0,6]
[Termination (ms): 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0
Avg: 0,0, Min: 0,0, Max: 0,0, Diff: 0,0]
[Termination Attempts : 5 8 2 11 5 6 6 5 5 7 4 7 2 9 8 5 7 8
Sum: 110, Avg: 6, Min: 2, Max: 11, Diff: 9]
[GC Worker End (ms): 9122246,4 9122246,6 9122246,7 9122246,6 9122246,7 9122246,7 9122246,5 9122246,7 9122246,5 9122246,5 9122246,6 9122246,7 9122246,8 9122246,4 9122246,6 9122246,5 9122246
,7 9122246,8
Avg: 9122246,6, Min: 9122246,4, Max: 9122246,8, Diff: 0,3]
[GC Worker (ms): 179,8 179,9 180,0 179,8 179,9 179,9 179,6 179,8 179,6 179,5 179,6 179,6 179,7 179,3 179,5 179,4 179,4 179,5
Avg: 179,7, Min: 179,3, Max: 180,0, Diff: 0,7]
[GC Worker Other (ms): 10,7 10,7 10,8 10,8 10,9 10,9 11,0 11,0 11,0 11,1 11,1 11,1 11,2 11,2 11,2 11,2 11,3 11,3
Avg: 11,0, Min: 10,7, Max: 11,3, Diff: 0,6]
[Clear CT: 2,8 ms]
[Other: 2343,4 ms]
[Choose CSet: 0,1 ms]
[Ref Proc: 2327,7 ms]
[Ref Enq: 1,9 ms]
[Free CSet: 8,2 ms]
[Eden: 3408M(3408M)->0B(3400M) Survivors: 272M->280M Heap: 9998M(18432M)->6638M(18432M)]
[Times: user=3,26 sys=0,02, real=2,54 secs]
Total time for which application threads were stopped: 2,5434370 seconds
The only phase of GC which makes problems is 'Reference processing'. But the log looks strange: soft, weak, final and jni references processing took very little time. But overall time is 2,5 seconds. Or it can be even more, up to 10 seconds in worst cases.
Another pause (more comfortable) may look like:
2013-07-10T16:26:11.862+0400: 13907,965: [GC pause (young)
Desired survivor size 243269632 bytes, new threshold 4 (max 15)
- age 1: 69125832 bytes, 69125832 total
- age 2: 58756480 bytes, 127882312 total
- age 3: 52397376 bytes, 180279688 total
- age 4: 88850424 bytes, 269130112 total
13907,965: [G1Ergonomics (CSet Construction) start choosing CSet, predicted base time: 77,38 ms, remaining time: 122,62 ms, target pause time: 200,00 ms]
13907,965: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 427 regions, survivors: 33 regions, predicted young region time: 167,95 ms]
13907,965: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 427 regions, survivors: 33 regions, old: 0 regions, predicted pause time: 245,33 ms, target pause time: 200,00 ms]
13908,155: [SoftReference, 0 refs, 0,0041340 secs]13908,160: [WeakReference, 0 refs, 0,0023850 secs]13908,162: [FinalReference, 1393 refs, 0,0065970 secs]13908,169: [PhantomReference, 108 refs, 0,0018650 secs]13908,171: [JNI Weak Reference, 0,0000630 secs], 0,22008100 secs]
[Parallel Time: 188,4 ms]
[GC Worker Start (ms): 13907965,3 13907965,3 13907965,4 13907965,4 13907965,5 13907965,5 13907965,6 13907965,6 13907965,6 13907965,7 13907965,7 13907965,7 13907965,8 13907965,8 13907965,8 13907965,9 13907965,9 13907965,9
Avg: 13907965,6, Min: 13907965,3, Max: 13907965,9, Diff: 0,6]
[Ext Root Scanning (ms): 5,8 5,0 6,8 6,3 6,1 6,2 6,0 6,3 5,2 4,2 5,0 6,2 4,5 6,0 17,1 4,4 6,2 5,3
Avg: 6,3, Min: 4,2, Max: 17,1, Diff: 12,9]
[Update RS (ms): 24,8 26,0 23,9 24,1 24,1 24,1 24,2 23,9 25,0 25,2 25,1 24,1 26,0 24,3 13,7 25,7 24,2 24,7
Avg: 24,1, Min: 13,7, Max: 26,0, Diff: 12,2]
[Processed Buffers : 30 20 9 16 16 19 20 21 22 12 30 17 17 20 12 20 17 22
Sum: 340, Avg: 18, Min: 9, Max: 30, Diff: 21]
[Scan RS (ms): 7,5 7,1 7,2 7,5 7,6 7,5 7,5 7,6 7,1 7,4 7,6 7,2 7,2 7,4 7,2 7,5 7,0 7,7
Avg: 7,4, Min: 7,0, Max: 7,7, Diff: 0,7]
[Object Copy (ms): 133,1 133,1 133,2 133,1 133,2 133,1 133,2 133,1 133,5 134,0 133,0 133,2 133,0 132,9 132,6 133,1 133,2 132,9
Avg: 133,1, Min: 132,6, Max: 134,0, Diff: 1,3]
[Termination (ms): 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0
Avg: 0,0, Min: 0,0, Max: 0,0, Diff: 0,0]
[Termination Attempts : 1 3 1 1 1 1 1 1 1 1 2 3 2 1 1 1 1 1
Sum: 24, Avg: 1, Min: 1, Max: 3, Diff: 2]
[GC Worker End (ms): 13908136,6 13908136,9 13908136,5 13908136,7 13908136,7 13908136,8 13908136,7 13908136,7 13908136,8 13908136,8 13908136,5 13908136,6 13908136,5 13908136,5 13908136,5 13908136,5 13908136,8 13908136,6
Avg: 13908136,7, Min: 13908136,5, Max: 13908136,9, Diff: 0,4]
[GC Worker (ms): 171,3 171,6 171,1 171,2 171,2 171,3 171,1 171,1 171,1 171,2 170,8 170,9 170,7 170,7 170,7 170,6 171,0 170,7
Avg: 171,0, Min: 170,6, Max: 171,6, Diff: 0,9]
[GC Worker Other (ms): 17,2 17,2 17,3 17,3 17,4 17,4 17,5 17,5 17,5 17,5 17,6 17,6 17,7 17,7 17,7 17,7 17,8 17,8
Avg: 17,5, Min: 17,2, Max: 17,8, Diff: 0,6]
[Clear CT: 1,6 ms]
[Other: 30,1 ms]
[Choose CSet: 0,1 ms]
[Ref Proc: 17,1 ms]
[Ref Enq: 0,9 ms]
[Free CSet: 7,4 ms]
[Eden: 3416M(3416M)->0B(3456M) Survivors: 264M->224M Heap: 7289M(18432M)->3912M(18432M)]
[Times: user=3,16 sys=0,00, real=0,22 secs]
Reference processing is still longest phase, but it's much shorter. ParallelRefProcEnabled wasn't be a cure for my problem. I've also tried to change size of young gen. It also not helped. Setting different -XX:MaxGCPauseMillis, more relaxed 600ms or more strict 100, results in still bad throughput.
CMS performance is even worse than G1 with parameters:
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly
Young gen collections going longer and more often.
I'm totally confused with described logs. Tomorrow I'll try to move Couchbase instance to another node in order to check if it's freezes GC threads.
But, if Couchbase is not the point, maybe someone could explain me meaning of the logs. Or maybe there are some magic CMS parameters to fix that thing.
I'll be very glad for any help!
Problem was fixed by ourselves. I we've got a new rule - NEVER install Couchbase near JVM.
In the past we had such problem with instance Postgresql conflicting with Couchbase because Couchbase likes to grab all disk ops and Postgresql cannot commit anything.
So, isolate Couchbase and everything gonna be allright.
Related
Description ENGINE LOG in IBM ILOG CPLEX
I want to understand engine log of IBM ILOG CPLEX studios for a ILP model. I have checked there documentation also but could not able to get clear idea. Example of Engine log : Version identifier: 22.1.0.0 | 2022-03-09 | 1a383f8ce Legacy callback pi Tried aggregator 2 times. MIP Presolve eliminated 139 rows and 37 columns. MIP Presolve modified 156 coefficients. Aggregator did 11 substitutions. Reduced MIP has 286 rows, 533 columns, and 3479 nonzeros. Reduced MIP has 403 binaries, 0 generals, 0 SOSs, and 129 indicators. Presolve time = 0.05 sec. (6.16 ticks) Found incumbent of value 233.000000 after 0.07 sec. (9.40 ticks) Probing time = 0.00 sec. (1.47 ticks) Tried aggregator 2 times. Detecting symmetries... Aggregator did 2 substitutions. Reduced MIP has 284 rows, 531 columns, and 3473 nonzeros. Reduced MIP has 402 binaries, 129 generals, 0 SOSs, and 129 indicators. Presolve time = 0.01 sec. (2.87 ticks) Probing time = 0.00 sec. (1.45 ticks) Clique table members: 69. MIP emphasis: balance optimality and feasibility. MIP search method: dynamic search. Parallel mode: deterministic, using up to 8 threads. Root relaxation solution time = 0.00 sec. (0.50 ticks) Nodes Cuts/ Node Left Objective IInf Best Integer Best Bound ItCnt Gap * 0+ 0 233.0000 18.0000 92.27% * 0+ 0 178.0000 18.0000 89.89% * 0+ 0 39.0000 18.0000 53.85% 0 0 22.3333 117 39.0000 22.3333 4 42.74% 0 0 28.6956 222 39.0000 Cuts: 171 153 26.42% 0 0 31.1543 218 39.0000 Cuts: 123 251 20.12% 0 0 32.1544 226 39.0000 Cuts: 104 360 17.55% 0 0 32.6832 212 39.0000 Cuts: 102 456 16.20% 0 0 33.1524 190 39.0000 Cuts: 65 521 14.99% Detecting symmetries... 0 0 33.3350 188 39.0000 Cuts: 66 566 14.53% 0 0 33.4914 200 39.0000 Cuts: 55 614 14.12% 0 0 33.6315 197 39.0000 Cuts: 47 673 13.77% 0 0 33.6500 207 39.0000 Cuts: 61 787 13.72% 0 0 33.7989 206 39.0000 Cuts: 91 882 13.34% * 0+ 0 38.0000 33.7989 11.06% 0 0 33.9781 209 38.0000 Cuts: 74 989 10.58% 0 0 34.0074 209 38.0000 Cuts: 65 1043 10.51% 0 0 34.2041 220 38.0000 Cuts: 63 1124 9.99% 0 0 34.2594 211 38.0000 Cuts: 96 1210 9.84% 0 0 34.3032 216 38.0000 Cuts: 86 1274 9.73% 0 0 34.3411 211 38.0000 Cuts: 114 1353 9.63% 0 0 34.3420 220 38.0000 Cuts: 82 1402 9.63% 0 0 34.3709 218 38.0000 Cuts: 80 1462 9.55% 0 0 34.4494 228 38.0000 Cuts: 87 1530 9.34% 0 0 34.4882 229 38.0000 Cuts: 97 1616 9.24% 0 0 34.5173 217 38.0000 Cuts: 72 1663 9.16% 0 0 34.5545 194 38.0000 Cuts: 67 1731 9.07% 0 0 34.5918 194 38.0000 Cuts: 76 1786 8.97% 0 0 34.6094 199 38.0000 Cuts: 73 1840 8.92% 0 0 34.6226 206 38.0000 Cuts: 77 1883 8.89% 0 0 34.6421 206 38.0000 Cuts: 53 1928 8.84% 0 0 34.6427 213 38.0000 Cuts: 84 1982 8.83% Detecting symmetries... 0 2 34.6427 213 38.0000 34.6478 1982 8.82% Elapsed time = 0.44 sec. (235.86 ticks, tree = 0.02 MB, solutions = 4) GUB cover cuts applied: 32 Cover cuts applied: 328 Implied bound cuts applied: 205 Flow cuts applied: 11 Mixed integer rounding cuts applied: 17 Zero-half cuts applied: 35 Gomory fractional cuts applied: 1 Root node processing (before b&c): Real time = 0.43 sec. (235.61 ticks) Parallel b&c, 8 threads: Real time = 0.27 sec. (234.23 ticks) Sync time (average) = 0.11 sec. Wait time (average) = 0.00 sec. ------------ Total (root+branch&cut) = 0.71 sec. (469.84 ticks) Mainly I want to understand what are nodes,left,gap,root node processing, parallel b&c. I hope anyone of you will give a resource or explain it clearly so that it can be helpful when someone starts using IBM ILOG CPLEX studio in future Thanks a lot in advance I am expecting for someone to fill knowledge gaps regarding Engine log of IBMs ILOG CPLEX studio
I recommend Progress reports: interpreting the node log https://www.ibm.com/docs/en/icos/12.8.0.0?topic=mip-progress-reports-interpreting-node-log
How to tune SparkPageRank example application for shorter garbage collection?
I am running a Spark application in a 7 node cluster - 1 driver and 6 executors on amazon EC2 machines. I use 6 m4.2xlarge instances with 1 executor each. They have 8 cores each. The driver is on a m4.xlarge VM, which had 4 cores. The spark version is 2.1.1. I use the following command to start SparkPageRank application. spark-submit \ --name "ABC" \ --master spark://xxx:7077 \ --conf spark.driver.memory=10g \ --conf "spark.app.name=ABC" \ --conf "spark.executor.extraJavaOptions=-XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:ConcGCThreads=5" \ --class org.apache.spark.examples.SparkPageRank \ --executor-memory 22g \ /home/ubuntu/spark-2.1.1/examples/target/scala-2.11/jars/spark-examples_2.11-2.1.1.jar /hdfscheck/pagerank_data_11G_repl1.txt 4 The GC time using these configuration comes out to be really high. Here is a chunk of the GC log for one of the executor: 1810.053: [GC pause (GCLocker Initiated GC) (young), 0.1694102 secs] [Parallel Time: 167.8 ms, GC Workers: 8] [GC Worker Start (ms): Min: 1810053.2, Avg: 1810053.3, Max: 1810053.4, Diff: 0.1] [Ext Root Scanning (ms): Min: 0.2, Avg: 0.4, Max: 0.7, Diff: 0.5, Sum: 2.9] [Update RS (ms): Min: 12.4, Avg: 12.7, Max: 13.2, Diff: 0.7, Sum: 101.4] [Processed Buffers: Min: 11, Avg: 12.9, Max: 16, Diff: 5, Sum: 103] [Scan RS (ms): Min: 29.4, Avg: 29.8, Max: 30.1, Diff: 0.7, Sum: 238.7] [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [Object Copy (ms): Min: 124.5, Avg: 124.6, Max: 124.7, Diff: 0.1, Sum: 996.9] [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [Termination Attempts: Min: 1, Avg: 2.2, Max: 5, Diff: 4, Sum: 18] [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1] [GC Worker Total (ms): Min: 167.5, Avg: 167.5, Max: 167.6, Diff: 0.1, Sum: 1340.2] [GC Worker End (ms): Min: 1810220.8, Avg: 1810220.8, Max: 1810220.8, Diff: 0.0] [Code Root Fixup: 0.0 ms] [Code Root Purge: 0.0 ms] [Clear CT: 0.4 ms] [Other: 1.2 ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.5 ms] [Ref Enq: 0.0 ms] [Redirty Cards: 0.4 ms] [Humongous Register: 0.0 ms] [Humongous Reclaim: 0.0 ms] [Free CSet: 0.1 ms] [Eden: 992.0M(960.0M)->0.0B(960.0M) Survivors: 160.0M->160.0M Heap: 14.6G(22.0G)->13.8G(22.0G)] [Times: user=1.34 sys=0.00, real=0.17 secs] (More at https://pastebin.com/E5bbQZgD) I could only see one fishy thing that the concurrent-mark-end took a lot of time. I would appreciate if someone could tell me how to tune garbage collection for this particular case. The VM on which driver node is located has 16GB of memory, whereas the executor VMs have 32GB memory.
(Not really an answer but just a collection of hints to help out). My driver node has 16GB of memory I don't think it's the case given you executed spark-submit with spark.driver.memory=10g. You should use --driver-memory instead (which is just a shortcut, but makes things a little easier to remember): --driver-memory MEM Memory for driver (e.g. 1000M, 2G) (Default: 1024M). Regarding your main question, the high use of GC that seems to be how the PageRank algorithm works. Note the high use of Shuffle Write with Input not that large. I also think that the GC time is not that long as compared to Task Time. I'm concerned with RDD Blocks being only 2 as that seems to suggest the parallelism being very low, but that might be how it should work. run-example SparkPageRank The following can be replaced with a simple run-example SparkPageRank (as described in Spark's Where to Go from Here) spark-submit ... \ --class org.apache.spark.examples.SparkPageRank ... \ /home/ubuntu/spark-2.1.1/examples/target/scala-2.11/jars/spark-examples_2.11-2.1.1.jar
Generate random binaries with avg hamming distance of 50%?
I want to generate binaries, where the average hamming distance between the items is around 50%. The second condition is that the distance should not fall below ~40% or go above ~60%. Another complication is that the items are not generated in sequence, but once in a while and I don't want to loop over all of the items to check and regenerate, because it will become a slow process after a while. Is there a mechanism or algorithm to achieve this ? Currently I use the following code : def rand(size): op = np.random.uniform() return np.random.choice([0,1], size=size, p=[op, 1-op] ) but it breaks even when I generate 10 items f.e. (hamming dist) : [ [ 0 2510 8209 4305 3896 1619 7231 6356 8103 3265] [2510 0 8131 4347 3940 1697 7219 6334 8037 3305] [8209 8131 0 5858 6449 9312 2100 3317 1030 7196] [4305 4347 5858 0 4661 4088 5598 5311 5764 4590] [3896 3940 6449 4661 0 3485 6093 5650 6385 4251] [1619 1697 9312 4088 3485 0 8034 6739 9152 2716] [7231 7219 2100 5598 6093 8034 0 3831 2238 6510] [6356 6334 3317 5311 5650 6739 3831 0 3405 5933] [8103 8037 1030 5764 6385 9152 2238 3405 0 7112] [3265 3305 7196 4590 4251 2716 6510 5933 7112 0]] min: 1030 Avg distance : 0.470624% btw. binaries are 10 000 bits.
So far the following solution seems to behave as to my expectation. def rand(size): return [np.random.randint(0,2) for _ in xrange(size)] will update when I do more extensive tests, if it is ok.
Can you help me to identify the rounding of this application?
I've a application that output chunk of buffers that represent 1/96 of beat (lets call them pulses), using a Sample Rate of 44100. At constant 120 BPM, I have 2 beat per second, so 22050 samples per beat, thus 229,6875 samples per pulse. These are the first values I got from the application: 0 230 459 689 919 1148 1378 1608 1838 2067 2297 2527 2756 2986 3216 3445 3675 3905 4134 4364 4594 4823 5053 5283 5512 5742 5972 6202 6431 Notice two things: it rounds the values using Round half to Even; the distance between buffers can be 229 or 230 due to the rounding. At constant 190 BPM instead, I have 145,0657895 samples per pulse. First values I got: 0 145 290 435 580 725 870 1015 1161 1306 1451 1596 1741 1886 2031 2176 2321 2466 2611 2756 2901 3046 3191 3337 3482 3627 3772 3917 4062 As before, Round half to Even, and the distance now can be 145 or 146. Well, nothing hard till here. Now! If I start the application at 120 BPM and after 25 pulse I switch to 190 BPM, I got a weird distance after the switch: 0 230 // distance 230 459 // distance 229 689 // distance 230 919 // distance 230 1148 // distance 229 1378 // distance 230 1608 // distance 230 1838 // distance 230 2067 // distance 229 2297 // distance 230 2527 // distance 230 2756 // distance 229 2986 // distance 230 3216 // distance 230 3445 // distance 229 3675 // distance 230 3905 // distance 230 4134 // distance 229 4364 // distance 230 4594 // distance 230 4823 // distance 229 5053 // distance 230 5283 // distance 230 5512 // distance 229 5742 // distance 230 - here I switch 5887 // distance 145 6032 // distance 145 6177 // distance 145 6322 // distance 145 6468 // distance 146 Why that last 146 values (6468)? In your opinion, due to "what" the distance between prev buffer is 146 and not 145? Tried to round next/prev at each iterations, but it seems correct to get 145 as value there. Instead its 146. It's confusing all my counters. Any clues?
229.6875 * 25 = 5742.1875 145.0657895 * 5 = 725.3289475 5742.1875 + 725.3289475 = 6467.5164475 rounding to 6468 Note that underlying calculations are made in exact (merely float) numbers
How to calculate Total average response time
Below are the results sampler_label count average median 90%_line min max Transaction1 2 61774 61627 61921 61627 61921 Transaction2 4 82 61 190 15 190 Transaction3 4 1862 1317 3612 1141 3612 Transaction4 4 1242 915 1602 911 1602 Transaction5 4 692 608 906 423 906 Transaction6 4 2764 2122 4748 1182 4748 Transaction7 4 9369 9029 11337 7198 11337 Transaction8 4 1245 890 2168 834 2168 Transaction9 4 3475 2678 4586 2520 4586 TOTAL 34 6073 1381 9913 15 61921 My question here is how is total average response time is being calculated (which is 6073)? Like in my result I want to exclude transaction1 response time and then want to calculate Total average response time. How can I do that?
Total Avg Response time = ((s1*t1) + (s2*t2)...)/s s1 = No of times transaction 1 was executed t1 = Avg response time for transaction 1 s2 = No of times transaction 2 was executed t2 = Avg response time for transaction 2 s = Total no of samples (s1+s2..) In your case, except transaction1 all other transactions have been executed 4 times. So, simple avg of (82, 1862, 1242...) should give the result you wanted.