Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DONT MERGE: Not leak memory #1572

Closed
wants to merge 3 commits into from
Closed

DONT MERGE: Not leak memory #1572

wants to merge 3 commits into from

Conversation

ch1bo
Copy link
Member

@ch1bo ch1bo commented Aug 17, 2024

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 🐛 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

@ch1bo ch1bo self-assigned this Aug 17, 2024
@ch1bo ch1bo added the bug 🐛 Something isn't working label Aug 17, 2024
Copy link

github-actions bot commented Aug 17, 2024

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
Copy link
Member Author

ch1bo commented Aug 17, 2024

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

image

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 ch1bo force-pushed the not-leak-memory branch 2 times, most recently from a49ee79 to aa0238f Compare August 17, 2024 15:12
@ch1bo
Copy link
Member Author

ch1bo commented Aug 21, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something isn't working
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

1 participant