A Nano node typically requires quite many disk operations. It’s recommended to use an SSD drive over a spinning disk to get enough performance, especially during bootstrapping (syncing) of the ledger but also during high transaction load. There is a simple way to gain even higher performance and that is running the whole Nano ledger from a RAMdisk (disk storage hosted in volatile memory). That will not only drastically improve read/write speed but also slightly prolong the life-span of your SSD due to how the NAND Flash technology works. A typical drive can handle 150 TB written which is equal to 80GB/day for 5 years or around 1MB/s continuous write speed. However, no need to fear that the node will kill your disk because the node does most of the continuous work in RAM already and a lot more reading than writing.
This guide was tested on Ubuntu 19 but should be very similar on most Linux based systems. The current ledger size is 7GB on the beta network and 20GB on the main network. Thus, to fit the ledger (with some margin) and still get enough RAM left for the node you need around 16GB installed RAM for beta and 32GB for main. Or if you just want to use this guide to run other smaller applications, please continue.
Setting up a ramdisk
Mounting a ramdisk in Linux is very easy and only require two lines of code. The more complicated part comes where you save the ramdisk to disk upon system shutdown and then reload the ramdisk on boot. That is optional but recommended for usability.
1.Create a mount point for the ramdisk
sudo mkdir /mnt/ramdisk
2. Mount the ramdisk. 16G means the max size will be 16GB. It will not use more RAM than the data you put on it so you can make it big but make sure to have some margin to the Nano ledger. Please check that first.
sudo mount -t tmpfs -o rw,size=16G tmpfs /mnt/ramdisk
3. Check that the mount was successful and has the expected size
4. You can now try to put some data on it by locating /mnt/ramdisk. If you change your mind you can unmount it (and lose all data) with the following:
sudo umount /mnt/ramdisk
Automate the ramdisk
5a. First, make the ramdisk mount on boot. But be careful editing this file, do exactly as written here and don’t remove any existing text. Note that “nano” is an editing program and has nothing to do with Nano.
sudo nano /etc/fstab
5b. Paste the following line at the bottom (use any size you want, here we use 16G which is 16GB). Close the editor with ctrl+x and accept saving:
tmpfs /mnt/ramdisk tmpfs rw,size=16G 0 0
Optional: Reboot the computer and check that the ramdisk is mounted on /mnt/ramdisk
6a. Data in RAM is killed when shutting down a computer (at least with today’s volatile memory technology). Therefore, we will also allow the system to save the ramdisk to a local drive and reload the data on the next boot. For that, we need someplace to store it. Make sure you have enough disk space. In this guide, we use a home directory. You can for example use /mnt/ramdisk_backup instead if there is disk space available on the root partition. You will need the double amount of free disk space as the size of the largest file (Nano ledger) because of the way rsync copy works.
6b. Then a service is set up to do the saving on shutdown. Open a new file:
sudo nano /lib/systemd/system/ramdisk-sync.service
Then paste this (change “user” in both places to your current account username). Technically the loading could be done here as well by using “ExecStart” but I struggled to get the right permissions for the files because I’m not using root. It will be done in another step instead:
ExecStop=/usr/bin/rsync -a /mnt/ramdisk/ /home/user/ramdisk_backup/
6c. Enable, start and check the status of the service:
sudo systemctl enable ramdisk-sync.service
sudo systemctl start ramdisk-sync.service
sudo systemctl status ramdisk-sync
6d. Verification of rsync. By stopping the service, any data in /mnt/ramdisk will now be copied to the backup folder (which can take a few minutes). Then check the status again and make sure there is no warning. Finally, start the service.
sudo systemctl stop ramdisk-sync.service
sudo systemctl status ramdisk-sync
sudo systemctl start ramdisk-sync.service
7a. You probably also want the ramdisk to reset its content on reboot. We do this with a cronjob but first, we create a script to make things easier to test:
sudo nano /usr/local/bin/ramdisk_restore
Paste this (don’t forget to change username):
/usr/bin/rsync -r /home/user/ramdisk_backup/ /mnt/ramdisk/
7b. Set execution rights and enable cronjob. If crontab asks for an editor, choose nano 😉
sudo chmod +x /usr/local/bin/ramdisk_restorecrontab -e
Paste this at the bottom. It will run the script on computer boot:
8. It’s a good time to place some test files on the ramdisk, make a reboot and check if they are still there. Also check if data is in the backup dir. If you store large files in the ramdisk the shutdown will take longer due to the saving. For the Nano ledger, maybe up to a minute depending on disk speed. If everything is working you can continue to the next step to learn how to run the Nano node on the new disk.
Optimize the Nano Node
9. Copy the node data, usually from /home/user/Nano or for the beta network it is /home/user/NanoBeta. ~ is a substitute for your home dir.
cp -a ~/Nano/. /mnt/ramdisk/Nano
10. Create another script that will launch the node. I will only cover running the node as “daemon” in this guide and not via docker. I’m sure it’s possible but may be harder to control the boot sequence since the data needs to be copied to the ramdisk before the node is started.
sudo nano /usr/local/bin/nanonode_start
Paste the text below and make changes for your own path accordingly. We point the data_path to the new ramdisk location.
/home/user/nano-node/nano_node --daemon --data_path=”/mnt/ramdisk/Nano”
If using docker it would look something like this (keep in mind, without the normal restart flag it will not restart if crashed). This is untested:
docker run -d \
-p 7075:7075 \
-p [::1]:7076:7076 \
-v /mnt/ramdisk:root \
--name nanov20 \
11a. Kill your nano node if running. Change permission and try the script.
sudo chmod +x /usr/local/bin/nanonode_start/usr/local/bin/nanonode_start
11b. Check that data.ldb is being updated on the new ramdisk (for example with “ls -l” command. If everything is working you could also allow the crontab to handle the nano launch. Here we place the script call after the data copy to ensure the data is there before starting (one line). By using && we ensure that if the copy fails, the node will not be started.
I also suggest running the backup one time per day because if the computer is suddenly killed (power outage) you will have to bootstrap the ledger from when you last restarted the computer (which could be a very long time). That’s the second line 0 0 * * * (don’t forget changing the username).
Be aware that the small saving in disk life you get for running in RAM probably becomes negative if saving the files to disk every day. You can increase this to maybe one time every Sunday by using 0 0 * * 0.
@reboot /usr/local/bin/ramdisk_restore && /usr/local/bin/nanonode_start0 0 * * * /usr/bin/rsync -a /mnt/ramdisk/ /home/user/ramdisk_backup/
12. Try to make another reboot. The real data should now be saved, restored on reboot and the node should start. Enjoy the speed, especially if you didn’t have an SSD!
The ledger data will grow over time. That means you will have to keep an eye on the size of the ramdisk and increase when needed or install more RAM. This may change in the future when ledger pruning is in place and you only need to store the latest data.
Comparison of read/write speeds on different drives using Crystaldiskmark in Windows. Random speed using 4KiB Q1T1.
HDD (7k rpm Sata):
Read: 229 MB/s
Write: 223 MB/s
Read random: 0.8 MB/s
Write random: 2.6 MB/s
SSD (850 Evo 1TB Sata):
Read: 556 MB/s
Write: 523 MB/s
Read random: 31 MB/s
Write random: 93 MB/s
SSD (970 Evo 1TB NVMe):
Read: 3504 MB/s
Write: 3311 MB/s
Read random: 50 MB/s
Write random: 159 MB/s
RAMdisk (DDR4 2600MHz):
Read: 6594 MB/s
Write: 10636 MB/s
Read random: 382 MB/s
Write random: 323 MB/s
The opinions expressed by the Guest writer are their’s alone, and do not necessarily reflect the views of the Nano Foundation or any officer or employee thereof and the Nano Foundation is not responsible for the accuracy of the information supplied by the Guest writer. Any links to third party sites are for information only, and some may offer commercial services, such as online purchases, financial services or products which may be subject to additional regulation or which may not lawfully be promoted to you in your jurisdiction. Nano Foundation disclaims any and all liability for the acts, omissions and conduct of any such third parties. The inclusion of any such link is not an approval, endorsement or guarantee of that website, any information you may obtain from it or the site’s owners (or their products/services), nor any certification that the site is accurate, or suitable or lawful for you to view or use the same, dependent upon your location and applicable national and/or local laws. YOUR ACCESS TO AND USE OF ANY EXTERNAL SITE IS ENTIRELY AT YOUR OWN RISK. Please address any questions regarding third-party material direct to that party.