Menu
▾
▴
Re: [Astlinux-devel] Reducing memory usage as much as possible
|
From: Michael K. <mic...@ip...> - 2023-08-17 22:04:03
|
Yes that is amazing. I started playing with Astlinux sometime in 2005/6 I believe. Left it for a bit and came back to it and now have over 100 systems out there and looking to expand to much more! Thanks for the fix. Pretty sure we have never configured the /etc/inittab file so shouldn’t be an issue. So I made some changes to our office system (always ends up being the guinea pig) using noram, dropping out ethernet drivers (I assumed I needed vmxnet3 also as I use VMWare) and took out a few Asterisk modules from modules.conf. Its now running with 281 MB, Available 147 MB so around 135M usage. Looking at my monitoring over the last 3 months I only saw a 50M variation so I think the current setup should be fine. We get notified by Zabbix if it reduces below 50M. Lets see how it goes. Even though its only a single processor, I suspect an Intel Xeon Gold 5118 (1x) @ 2294 MHz will be fine. PS I have also noticed that it boots up faster. In my build system on Vultr I rebooted the system and could log back in around 45 seconds later. Nice! Regards Michael Knill From: Lonnie Abelbeck <li...@lo...> Date: Friday, 18 August 2023 at 1:50 am To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] Reducing memory usage as much as possible Cool how after almost 20 years, old AstLinux features become new again :-) A fix for the "Very Important" warning has been added to master [1]. This would be difficult to fix at the web interface level, other than disabling "Revert to Previous". I did discover a very minor issue with a "noram" configuration. If the /etc/inittab file was edited (rarely needed) the edited /etc/inittab is applied to the filesystem after /usr/sbin/chroot is called in the initrd, as such the default base image /etc/inittab is always used. A custom build for genx86_64-vm could customize the /etc/inittab here [2]. For the tmpfs root filesystem case, the initrd copies-forward the /etc/inittab file to the uncompressed tmpfs image before calling /usr/sbin/chroot. Again, should not be a big deal for a "noram" configuration. BTW, before this was fixed for the tmpfs case, AstLinux 1.3.10 through 1.4.2 ignored any user edits to the /etc/inittab file and nobody noticed :-) Additionally, if you wanted to build a custom genx86_64-vm image with "noram" enabled by default, you would add noram after astlive here [3]. Lonnie [1] https://github.com/astlinux-project/astlinux/commit/09eed53ddea8f45414195507aeee6d0f8edb9e92 [2] https://github.com/astlinux-project/astlinux/blob/master/project/astlinux/board/genx86_64-vm/target_skeleton/etc/inittab [3] https://github.com/astlinux-project/astlinux/blob/master/project/astlinux/board/genx86_64-vm/runnix.conf > On Aug 17, 2023, at 12:04 AM, Michael Knill <mic...@ip...> wrote: > > Wow thanks Lonnie that is fantastic and we will test it out. Gosh this will change things considerably. Will be even less once we pull out other modules we don’t use. Having such a lean image will mean that we don’t really need to explore difficult to manage containerisation options such as Docker. > Will update the System Tab so that you cannot perform the revert and upgrade as you mentioned. > > Regards > Michael Knill > > > From: Lonnie Abelbeck <li...@lo...> > Date: Thursday, 17 August 2023 at 1:59 am > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] Reducing memory usage as much as possible > > > > On Aug 16, 2023, at 3:41 AM, Michael Keuter <li...@mk...> wrote: > > > > > >> Am 16.08.2023 um 05:36 schrieb Michael Knill <mic...@ip...>: > >> > >> Hi Devs > >> Im looking to expand considerably and it will be all in the cloud. > >> Our current hosting provider allows us to overcommit CPU resources which works well for us as Astlinux uses nothing however memory is something that cannot be overcommitted and is actually the most expensive of all the resources. As such, I want to have a build that uses the minimal amount of memory I can possibly get away with safely for my small systems. Note this is only for the small systems which have very low usage and its very easy to add memory if required. > >> I believe have turned off as much as I can:<image002.png> So is there anything else I can turn off, no matter how small? > >> Can I get rid of tmpfs somehow since a read only file system is not necessary? > >> My ultimate goal is to have a VM template that I just push a button and its all built and ready to go and a minimal image will make this far more competitive for the mentioned high end hosting. Of course we could just use Vultr which we love but you get what you pay for ☹ > >> Regards > >> Michael Knill > >> Managing Director > >> D: +61 2 6189 1360 > >> P: +61 2 6140 4656 > >> E: mic...@ip... > >> W: ipcsolutions.com.au > >> <image001.png>Smarter Business Communications > > > > Hi Michael, > > > > I have here an older list of packages, which I disabled (from the defaults) for Alix boards (at that time): > > > > Asterisk: dahdi_echocan_oslec, prosody off > > Asterisk: dahdi_no_card_firmware on > > Hardware handling: monit, zabbix_proxy, zabbix off > > Libraries/Networking: pjsip, 'Asterisk PRI Support' off > > Networking apps: keepalived, netsnmp, openldap-server, strongswan off > > > > These were all packages that were not needed on those boxes. > > > > Michael > > Micheal Keuter brings up a good point. Though disabling packages in the build system may not be required. > > In AstLinux, memory usage has two elements: > > 1) Standard application and kernel RAM usage. > 1a) Reducing memory usage can be achieved by only starting needed services and tuning the /etc/rc.modules to comment-out unused NIC modules. > > 2) The Read-Only root filesystem "/" is by default mounted uncompressed using tmpfs. > 2a) Reducing memory usage can be achieved by adding "noram" to the KCMD of the /oldroot/cdrom/os/*run.conf file(s). In the "noram" case the root filesystem "/" is mounted compressed using squashfs, via /dev/loop0. > > First, a little history. > > Back in the day when CompactFlash (CF) storage was the norm and boards contained 256 MB or more RAM, the Read-Only root filesystem "/" was copied to RAM (tmpfs). This served two purposes, > 1) no realtime uncompressing of the squashfs run image noticeably reduced file access latency and speed on single core 500 Mhz (or less) CPUs > 2) root filesystem access was much faster using RAM (tmpfs) rather than a loop mount directly off CF storage. > > In later years, while the advantages of the tmpfs root filesystem were less pronounced as SATA storage appeared and multi-core CPUs, there are still advantages today to make a tmpfs root filesystem still the default. Eliminating the loop mount directly off the storage is probably the main advantage today (KISS), and systems with 1 GB RAM or more there is no practical RAM disadvantage. > > As per Michael Knill's use case above, there may be a legitimate case for adding "noram" in the KCMD of the /oldroot/cdrom/os/*run.conf file(s). > > Demonstrate via an example. > > Using the latest pre-release [1] Guest VM x86-64bit ISO [2] with Proxmox 8, standard build using Asterisk 20.4.0 with pjsip loaded. > > The Proxmox VM is configured with 2-cores and 512 MB RAM > > Default case: > Proxmox: Memory usage 38.13% (195.24 MiB of 512.00 MiB) > -- > Host Name: pbx.astlinux > Linux: 5.10.179-astlinux x86_64 > CPU: Common KVM processor (2x) @ 2096 MHz > RAM: 489 MB, Available 253 MB > Board Type: genx86_64-vm > Hardware: KVM Hypervisor Guest VM > -- > none on / type tmpfs (ro,relatime,size=134128k) > none 143.4M 143.4M 0 100% / > > Note that 143.4 MB of RAM is used for the root filesystem. > > Next, add "noram" to the KCMD= line ... > -- > # mount -o rw,remount /oldroot/cdrom > > Edit the KCMD= line by adding noram after astlive > # vi /oldroot/cdrom/os/astlinux-1.5-5855-4d7596.run.conf > After the change, it should show... > # grep '^KCMD=' /oldroot/cdrom/os/astlinux-1.5-5855-4d7596.run.conf > KCMD="root=/dev/ram0 rw init=/linuxrc astlinux=genx86_64-vm astimg=astlinux-1.5-5855-4d7596.run astkd=auto asturw=auto astlive noram libata.dma=3" > > # mount -o ro,remount /oldroot/cdrom > -- > > Very Important -> With "noram" in the KCMD, never perform a firmware "Revert to Previous" followed by an "Upgrade with New" without rebooting immediately after the firmware revert. > > "noram" case: > Proxmox: Memory usage 19.81% (101.42 MiB of 512.00 MiB) > -- > Host Name: pbx.astlinux > Linux: 5.10.179-astlinux x86_64 > CPU: Common KVM processor (2x) @ 2096 MHz > RAM: 489 MB, Available 400 MB > Board Type: genx86_64-vm > Hardware: KVM Hypervisor Guest VM > -- > /dev/loop0 on / type squashfs (ro,relatime) > /dev/loop0 51.1M 51.1M 0 100% / > > Note that no extra RAM is used, the 51.1 MB is the compressed squashfs run image directly mounted off storage. > > Interestingly, the AstLinux 400 MB vs. 253 MB Available RAM closely matches the tmpfs root filesystem size, but the Proxmox Memory usage only dropped to 101 MB vs. 195 MB. > > Additional RAM (albeit minor) RAM reduction > Disable unused NIC modules (Proxmox example) > -- > pbx ~ # cat /etc/rc.modules > ## These modules get modprobe'd when the system starts up. > ## > ## Comment out any modules you don't need. > ## > ## Ethernet support > ## Virtual first, then Emulated > virtio_net > #vmxnet3 > #pcnet32 > #e1000 > #e1000e > #8139too > -- > > In summary, setting "noram" in the /oldroot/cdrom/os/*run.conf KCMD should be a production-worthy option for special low-RAM VM situations, but since it has not been used by default, testing should be performed. Don't forget the "Very Important" notice above. > > Also note that once "noram" in the /oldroot/cdrom/os/*run.conf KCMD is defined, it is automatically carried forward on future upgrades. > > Lonnie > > [1] https://www.astlinux-project.org/dev.html > > [2] https://astlinux-project.org/beta/iso/astlinux-beta-genx86_64-vm.iso > > > > > > > > > > > > > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
