Thought maybe a generic ApisCP thread would be nice …
Reading a bit before installing, reading about the low memory mode:
Low-memory mode disables PHP-FPM by default, which improves memory usage at the consequence of higher latency and reduced security through global filesystem visibility beyond open_basedir limits.
I think I’ve been running Lighty+PHP-FPM on a VPS with very limited memory before …
But I guess @nem knows far more about this than I do … I don’t like the security implications, though.
Also, I guess I need to learn what’s OK to just do on the system directly as I would by habit, and when to use the panel’s own commands/interface.
Php-fpm is great, but, from personal experience, running php-fpm on a low memory system, kinda defeats the purpose. Probably the reason why @nem chose to disable.
Specially since a lower memory instance would require additional customization on the standard php-fpm config, to be resource friendly, which might impact the standard deployment/configs
On the topic of low-memory, it does prefer ISAPI, which can be overrode with
cpcmd scope:set cp.bootstrapper php_has_isapi false ; upcp -sb - it’ll recompile PHP and update platform configuration to PHP-FPM. Afterward
EditDomain -c apache,jail=1 --all to rebuild Apache configuration for all sites.
There’s additional security measures in ISAPI taken at the expensive of overhead. It’s not efficient after a certain number of sites because caches are aggregate, and huge memory caches aren’t efficient. I ran this policy for ~15 years without incident. It’s not the fastest, but certainly the most memory-efficient.
If you’re looking to shave more memory off,
cpcmd scope:set cp.headless true to remove the panel UI. You can still use its CLI tools, which reflect most of the panel API. It’s how I typically interact with it, especially for development.
If you need to enable the UI later on,
cpcmd scope:set cp.headless false. It’s how the licensing server operates
cpcmd scope:set cp.bootstrapper mail_enabled false ; upcp -sb - remove mail services from server, will still be able to send mail, but not receive (can still use smarthost).
I tried to install on 1 GB RAM and I can not complete the setup.
Can I just disable everything and install it later?
rm -rf /usr/local/apnscp then add
-s has_low_memory=true -s limit_memory_1gb=500 to the installer. This’ll allow you to bypass the minimum memory safety limits.
I got low memory mode enabled that disables php-fpm by default, would switch to it improve site speed.
Compared to my last setup on the same vm Apache 2.4 pre-fork Ruid2 7.3 running php via Mod_php the performance especially on heavier sites seem quite a bit slower.
Any benchmarks to qualify this? There’s a framework to help you benchmark in the docs that will allow you to get some numbers on pages/second.
One notable difference in ISAPI mode is that open_basedir is enabled to prevent one site from accessing files on another site. open_basedir adds extra stat calls to each directory in the filesystem as well as disables stat caches. It’s turned off when PHP-FPM is used as the FPM pools are jailed to account prior to startup.
open_basedir wouldn’t create an appreciable slowdown except under heavy load, but then again too running a threaded MPM (Event) would be faster than prefork/ruid2 all things being equal.
Play with enabling PHP-FPM to see if that improves throughput. If you’re still seeing an inconsistency feel free to reach out to me for further analysis.
cpcmd scope:set cp.bootstrapper php_has_isapi false
EditDomain -c apache,jail=1 --all
I managed to identify the issue it was a plugin on the site that was causing the issue disabling and re-enabling all plugins seem to fix the lag.
Dose switching to fpm disable Fortification or do you need to switch to fpm and change pool user to user to disable it am not planning to disable it.
Fortification works with both ISAPI and FPM. It originally developed as a way to improve security with ISAPI, but works with FPM as well.
Changing the pool to same-user will make it behave like cPanel/Plesk and too carries all of the security risks that led to a rise in firms like Sucuri/SiteLock. You’d also lose any benefits of Fortification.
Definitely keep Fortification on. If you need custom paths for a web app, look into Manifests as a way of whitelisting directories or even too place it in “Learning Mode” under Fortification.
So fortification only works if Apache user is executing the PHP file switch to user disable it then.
Correct. Fortification is intended to simplify managing privileges by an unprivileged user (“apache” in this case).
So, for a fresh install, should I opt for CentOS 7 or 8 now? (This will be for testing the panel, not production, at least not at first.)
So maybe v. 8, since I’m not that worried about no path opening for migration to whatever is next, after 2021 …?
There will be scripts for easy migration. CloudLinux already promised a such script. Maybe it’s best to wait and see.
CentOS 8. It’ll be required for reseller support once launched (xfs project quotas, cgroup v2 subtrees are necessary for online resource limits). I’ll have a clear migration path for C8’s spiritual successor once the dust settles, but it’s still too early to say which direction is optimal.
Worst case you can always use the server transfer tool to send your accounts to another platform.
If I install ApisCP should I use xfs?
Yes, it’s stable and doesn’t suffer from inode starvation like ext4.
Only possible problem with XFS (in my experience), is that you can only grow, never shrink the filesystem. (So if you’re moving images around and resize them, it might be an issue.)
Oh, just installed fresh. Had trouble getting netboot.xyz menu to load (I should probably file that issue with @SERIESN, but no rush), so I chose a CentOS 8 template … and just now I realized it’s
ext4 and not XFS … Should I reinstall?
Whoah what broke? Centos iso is available within the panel too.