DONT MERGE: Not leak memory

ch1bo commented 2 months ago

PR for a reminder of hacks we needed for hydra-doom to have long-lived, massively loaded hydra-nodes not use insane amount of memory.

The diff here has two potentially infinitely growing memory uses disabled:

No history on the API server
No outbound message cache for hydra network reliability (resending of messages).

Obviously we should tackle these properly and work with bounded memory.

TODO: Create a :bug: ticket out of this.

[ ] CHANGELOG updated or not needed
[ ] Documentation updated or not needed
[ ] Haddocks updated or not needed
[ ] No new TODOs introduced or explained herafter

github-actions[bot] commented 2 months ago

Transaction costs

Sizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using arbitrary values and results are not fully deterministic and comparable to previous runs.

Metadata
Generated at	2024-08-17 15:24:21.529172099 UTC
Max. memory units	14000000
Max. CPU units	10000000000
Max. tx size (kB)	16384

Script summary

Name	Hash	Size (Bytes)
νInitial	2fac819a1f4f14e29639d1414220d2a18b6abd6b8e444d88d0dda8ff	3799
νCommit	2043a9f1a685bcf491413a5f139ee42e335157c8c6bc8d9e4018669d	1743
νHead	bd9fad235c871fb7f837c767593018a84be3083ff80f9dab5f1c55f9	10194
μHead	c8038945816586c4d38926ee63bba67821eb863794220ebbd0bf79ee*	4607

The minting policy hash is only usable for comparison. As the script is parameterized, the actual script is unique per head.
Init transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	5189	5.71	2.25	0.44
2	5390	7.36	2.91	0.47
3	5591	8.46	3.34	0.49
5	5998	11.12	4.39	0.54
10	6998	18.02	7.12	0.66
56	16246	81.53	32.25	1.76

`Commit` transaction costs

This uses ada-only outputs for better comparability.

UTxO	Tx size	% max Mem	% max CPU	Min fee ₳
1	559	10.52	4.15	0.29
2	749	13.86	5.65	0.34
3	934	17.33	7.20	0.38
5	1309	24.65	10.44	0.48
10	2243	45.22	19.36	0.75
20	4103	95.99	40.76	1.40

`CollectCom` transaction costs

Parties	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
1	57	549	22.14	8.66	0.42
2	114	659	32.09	12.73	0.53
3	170	769	47.60	19.01	0.71
4	226	883	57.48	23.28	0.82
5	282	994	76.65	31.12	1.04
6	340	1100	90.78	37.24	1.20

Cost of Decrement Transaction

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	628	17.93	7.87	0.38
2	834	19.89	9.35	0.42
3	900	19.97	10.07	0.42
5	1161	22.65	12.58	0.48
10	1866	30.60	19.33	0.62
48	7681	93.82	71.57	1.76

`Close` transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	670	21.02	9.42	0.42
2	768	22.49	10.81	0.44
3	912	23.92	12.20	0.47
5	1350	28.04	16.02	0.55
10	2070	35.57	23.31	0.70
50	7873	99.01	83.41	1.90

`Contest` transaction costs

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	680	27.18	11.67	0.48
2	815	28.98	13.20	0.52
3	1034	31.36	15.30	0.56
5	1213	34.06	17.64	0.61
10	1986	44.21	26.21	0.78
38	6352	98.64	72.68	1.75

`Abort` transaction costs

There is some variation due to the random mixture of initial and already committed outputs.

Parties	Tx size	% max Mem	% max CPU	Min fee ₳
1	5056	17.51	7.61	0.57
2	5231	29.42	12.96	0.71
3	5361	42.94	18.99	0.87
4	5472	55.34	24.48	1.01
5	5520	66.33	29.23	1.14
6	5672	90.03	39.96	1.42

`FanOut` transaction costs

Involves spending head output and burning head tokens. Uses ada-only UTxO for better comparability.

Parties	UTxO	UTxO (bytes)	Tx size	% max Mem	% max CPU	Min fee ₳
5	0	0	5023	7.75	3.28	0.46
5	1	57	5056	8.88	3.99	0.47
5	5	285	5193	13.60	6.92	0.54
5	10	570	5362	19.06	10.39	0.62
5	20	1139	5702	30.19	17.43	0.77
5	30	1708	6042	42.10	24.80	0.94
5	40	2279	6384	53.23	31.84	1.09
5	50	2848	6723	64.37	38.89	1.25
5	81	4608	7769	99.92	61.18	1.74

End-to-end benchmark results

This page is intended to collect the latest end-to-end benchmark results produced by Hydra's continuous integration (CI) system from the latest master code.

Please note that these results are approximate as they are currently produced from limited cloud VMs and not controlled hardware. Rather than focusing on the absolute results, the emphasis should be on relative results, such as how the timings for a scenario evolve as the code changes.

Generated at 2024-08-17 15:28:44.378291425 UTC

Baseline Scenario

Number of nodes	1
Number of txs	3000
Avg. Confirmation Time (ms)	1.593998971
P99	2.2474213499999998ms
P95	1.9354736ms
P50	1.537023ms
Number of Invalid txs	0

Three local nodes

Number of nodes	3
Number of txs	9000
Avg. Confirmation Time (ms)	40.989157185
P99	212.10795307ms
P95	119.35618044999998ms
P50	18.515843500000003ms
Number of Invalid txs	0

ch1bo commented 2 months ago

Growing data structure like mentioned above could also be a reason for high cpu usage on otherwise idle hydra nodes. For example these here:

Both hydra-nodes have been running for 8 days. The preview one has a head open with 4 other nodes, but no significant L2 traffic. The mainnet one even has not a head open right now and just sits there idling.. still using 500mb of resident memory and CPU cycling?

ch1bo commented 2 months ago

Closing this as we have a proper issue now: #1581

cardano-scaling / hydra