What issues could we discuss here?

[andyoknen]

@Dennis-Volk
@only1question
@Yanotek
@tawmaz
@lostystyg

[lostystyg]

Probably something related to issues to not flood too much in their threads before some constructed ideas come out.

[MikkelRS]

So i am running the node on Debian 11.2, using v0.20.17, everything works OK, except ram usage creeps up over 20gb over a couple days, then crashes with:
EXCEPTION: 15dbwrapper_error
Fatal LevelDB error: IO error: /home/########/.pocketcoin/indexes/txindex/936640.ldb: Too many open files
pocketcoin in scheduler

terminate called after throwing an instance of 'dbwrapper_error'
what(): Fatal LevelDB error: IO error: /home/########/.pocketcoin/indexes/txindex/936640.ldb: Too many open files
Aborted

Any ideas? Looks like the node isnt able to properly close open files, then reaches a limit, which would coincide with the ram usage.

[tawmaz]

What does "ulimit -a" print out for file limit? I have had Ubuntu distro's run into issues with a file limit set to 1024, but that was normally with debug builds. If it is not set to a low file limit I would suggest opening a regular issue.

[MikkelRS]

#########@focusedmachine:$ cat /proc/sys/fs/file-max
9223372036854775807
#########@focusedmachine:$ ^C
#########@focusedmachine:~$ ulimit -a
real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 514879
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 514879
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

[andyoknen]

We have encountered a similar problem in the framework of working with a web socket - in linux, each tsp connection = a file, roughly speaking. Leveldb also operates with a fairly large number of files. Again, this is just a guess

[andyoknen]

@MikkelRS I can't be sure about the memory, but you can look at the SQLITE_DEFAULT_CACHE_SIZE variable in sqlite.c - Too large a value can cause a large RAM consumption.

Regarding the number of open files - maybe this setting can help - https://www.tecmint.com/increase-set-open-file-limits-in-linux/