These seem to all apply to LND and not CLN though, correct? I can open an issue on the CLN's repository.
Sorry yeah, I am remote into my desktop that is logged into the forum and the last part "There might be something similar in CLightning" did not make it.
Ok, so it looks like this could be all normal and due to the fact that my LN node is new. It is supposed to calm down...
At least for the CLN part, I'm not sure why core is using anything. Mine only has activity when blocks are found and even then not much.
How are you powering the RPi? I have seen some 5V adapters cause issues.
This is one of my favorites.... 5% over voltage with no load, add a load and I can get it to 5.5V / 10% over voltage, then bad things
tm happen.
![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2Fax48igmb.jpg&t=665&c=gUpWeTqFCqczRQ)
-Dave
Do you recall having your service using a significant amount of CPU and IO for a few days initially? When comparing to downloading and verifying the blockchain, CLN does not seem to be downloading much data or using much disk space, but it saturates the SSD IO and puts significant load on the CPU. My whole bitcoin directory for CLN currently uses only 82M of disk space. I see about 20 KB/s or less of up or down traffic for the node. lightningd at 36% and bitcoind at 110% CPU core usage.
I have been using the official 15W power supply. I have not had any obvious issue with it. What do you have exactly? I have not done any overclocking for my node, but as I mentioned got UASP and trim working for the SSD, and I use it for the OS as well, I do not use any SD card, I activated noatime. I would expect IO performance to be quite optimized for my RPI.
Maybe I should bump up bitcoind's dbcache temporarily to help CLN syncing faster with less IO operations? I had dbcache configured at 7368 MB when I downloaded and verified the blockchain, but since I brought it down to 300 MB... Maybe it is bitcoind that is currently creating the IO strain and not lightningd...
I will try increasing dbcache to 5000
Ok I looked at the details using htop, and what I see is that cln's bcli is writing to the disk at 10 MB/s constantly...
[moderator's note: consecutive posts merged]