Hello everyone! I have a similar issue as the poster in this thread: https://www.howtoforge.com/community/threads/optimizing-multi-php-fpm.81606/#post-386706 My configs looks something like this: pm = dynamic pm.max_children = 10 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 5 pm.max_requests = 0 The problem is, that this server belongs to a client of me. I have set up a system, that allows him to create sites through the ISPConfig Admin interface. But of course with each new site, another php-fpm pool is created. As of now, there are around 11 sites hosted on this system and the RAM is pretty much on it's limits all the time. As the server only has around 4GBs of RAM, that doesn't wonder me too much. But sadly it's not my decision to upgrade said server. To prevent this from happening, my client would need to recalculate the necessary RAM per instance of php-fpm and then modify the settings for each site, every time he want's to create a new site. That's not really an option either, as he's not that tech savvy. Is there a possibility to create a single pool for php-fpm, which all sites would then share? I know about the advantages of having multiple pools, but I don't see any possibility of doing that in the current constellation. Thank you very much in advance! Best regards, Patrick
@Jesse Norell I did that, but the problem persists. The server performance of the hosted websites is still more than bad, especially when using the CMS. I also created an issue in the official repo, but that was closed due to being more like a call for support or guidance. Is there really no way of unifying the php-fpm pools and let all / some of the hosted websites use the same pool? Best regards, Patrick
Here is my comment from the issue: My setup is as follows: I have a master server, that contains ISPConfig itself, then there is a another server for the database and one for the website installations. Currently there are around 15 websites hosted on the system like this. Due to the fact that a new php-fpm pool is created for every new website, the creation of the website has an overall effect on the available resources. From this it follows that with a corresponding load, the response times of the hosted websites become slower and slower, since the pools "fight each other" for resources. In addition, since I try to allocate as many resources as possible to each website, I have to change the poolconfig for all websites every time a new website is added, as the total memory then has to be distributed over even more pools. In addition to this setup, I run another server on which all configurations were made exactly as on this one and which even has a poorer hardware configuration, but the performance on this is significantly better with the same load and a similar number of websites. Here, however, all websites share a pool. It is clear to me that it makes sense to set the resources for individual websites individually in order to avoid a high number of hits on one page affecting the performance of the other pages. In this case, however, this is explicitly desired. Finally, my question. Is it possible to have all / or some of the websites explicitly use the same pool?
In fpm ondemand mode, there are no php processes started for each website (like in dynamic mode), they are started when a request is processed - so adding 1000 sites doesn't increase the resource usage if there aren't active requests for those sites, and having a single site with lots of requests may require tuning to allow more to be handled simultaneously (eg. higher max_children). You are tuning with different goals that a typical shared hosting server. Maximizing resource usage all the time makes sense for some scenarios, but it's not clear how your sites are setup. You can add alias domains to a website and they will share the pool config. That of course has all domains using the same document root, running the same code base, etc., but that might be what you're wanting? It doesn't immediately make sense (to me) how you would share a php-fpm pool in any other configuration (the pool definition sets the doc_root, user/group id, etc. - things that are all site specific unless your sites also share a docroot/codebase).
@Jesse Norell But exactly that is the problem. Due to the fact, that I have to "reserve" the memory in case the other hosted websites also receive a high load at the same moment, I can not set the max_children higher than [max_children_total (based whole server RAM minus other processes)] / [number of hosted websites] = [max_children_single_website]. If I had one single pool, that wouldn't be a problem, as I could just set max_children to the maximum possible amount based on the RAM and processors and all sites would have to share. While the other websites don't receive a high load, all the memory is available to those that do. No, actually each domain should lead to a different root dir, as each setup is for a different client. The root dir should be defined within the nginx conf file of the domain and I'm not sure which users/groups you mean, but the clients shouldn't per se be able to edit anything in the directory besides maybe upload some stuff via SFTP. All interactions with the source code of the installation should go through www-data and the CMS of the website. Within a normal Debian-based environment, the typical setup (before any alteration) with php-fpm and nginx only has a single fpm-pool, which is shared for all installations. This can of course be changed.
Which is quite insecure as all sites are run under the same user and therefore not well-suited for hosting environments, that's why ISPConfig does not use such a setup.
The php-fpm pool also sets a doc_root for the php daemon; the user and group I referred to is what the php daemon runs as (each website has is own user and group for security, whereas the default Debian config sets up a single user, www-data).
Could you recommend a tutorial or guide for this? Okay, of course I understand that. What are the risks here? Aside from the obvious problems that one site could be hacked and then other sites would be compromised. With appropriately selected file and folder rights, these dangers should be kept within limits. Thank you @Jesse Norell and @till for your kind help!
That is a default function which is not enabled by default, so you must enable it in System > Main Config if you wish to use it.
That pretty much summarizes is, when one site is compromised, it's likely a few simple steps away from all your sites being compromised (and from there, email accounts used by the sites are compromised, etc....). If you make the files root owned (or maybe create a dedicated system user which is not www-data), and the sites don't need to upload files, don't use a database, don't store session info, etc., you can limit some of the cross-site compromises. This makes all sites maintained by a central user, which is not the typical (shared) hosting environment, and is again with different goals than the normal ISPConfig usage scenarios. You will have to set most of this up manually (it might be easier to use a dedicated server without ISPConfig installed?). Also, it does not apply to most websites nowadays (ie. no database, no file uploads, etc.). When I tested this (last week?), vhost alias domains were setup with their own php-fpm pool and their own user/group, just like separate websites.
