Typescript

ac-parser-typescript/ac-parser-typescript.iml

@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<module version="4">
+  <component name="CheckStyle-IDEA-Module" serialisationVersion="2">
+    <option name="activeLocationsIds" />
+  </component>
+</module>

docker-compose.yml

@@ -11,7 +11,13 @@ services:
       # (~7.8 GiB here) and never gives it back: measured 6.17 GiB still held one hour after a
       # deep refresh of upms had finished, at <1% CPU. The cap is what forces the JVM to
       # collect rather than commit.
-      NEO4J_server_memory_heap_max__size: "2G"
+      # 2G -> 4G (2026-09-23): a deep ingest of upms2 (6311 Natural files) failed at batch 1601-1800
+      # with "allocation of an extra 34.2 MiB would use more than the limit 1.4 GiB ...
+      # dbms.memory.transaction.total.max threshold reached". That limit defaults to 70% of the heap,
+      # and one 200-file persist transaction now writes ~64k nodes / ~159k relationships (item 160
+      # positional nodes, copycode copies), which no longer fits in 1.4 GiB. 4G lifts the ceiling to
+      # 2.8 GiB. The idle-heap concern above still holds: G1PeriodicGCInterval returns it.
+      NEO4J_server_memory_heap_max__size: "4G"
       NEO4J_server_memory_heap_initial__size: "512M"
       # 512M -> 1G -> 3G -> 2G. The store has grown to 2.4 GB (1.2 GB of it range indexes), so 1G
       # covered only ~42% of it. 2G covers nearly all of it; the 2.5 GB of transaction logs are
@@ -36,8 +42,8 @@ services:
     # zero reserve. An OOM-kill mid-refresh leaves the graph half-updated, which is far worse than a
     # spare GB. This follows the page cache: Neo4j's own rule of thumb is heap + page cache + ~1G, so
     # 2G of cache means 6g here — 1G of reserve, not generosity. Do not raise the page cache without
-    # raising this too.
-    mem_limit: 6g
+    # raising this too. 6g -> 8g with the heap raise to 4G (same rule: 4G heap + 2G cache + reserve).
+    mem_limit: 8g
     volumes:
       - neo4j-data:/data
     healthcheck: