Array
(
[0] => Core
[1] => date
[2] => libxml
[3] => openssl
[4] => pcre
[5] => zlib
[6] => filter
[7] => hash
[8] => pcntl
[9] => readline
[10] => Reflection
[11] => SPL
[12] => session
[13] => standard
[14] => cgi-fcgi
[15] => bcmath
[16] => bz2
[17] => calendar
[18] => ctype
[19] => curl
[20] => dba
[21] => dom
[22] => enchant
[23] => mbstring
[24] => fileinfo
[25] => ftp
[26] => gd
[27] => gettext
[28] => gmp
[29] => iconv
[30] => imap
[31] => intl
[32] => json
[33] => ldap
[34] => exif
[35] => mysqlnd
[36] => odbc
[37] => PDO
[38] => pgsql
[39] => Phar
[40] => posix
[41] => pspell
[42] => recode
[43] => shmop
[44] => SimpleXML
[45] => soap
[46] => sockets
[47] => sqlite3
[48] => sysvmsg
[49] => sysvsem
[50] => sysvshm
[51] => tidy
[52] => tokenizer
[53] => xml
[54] => xmlwriter
[55] => xsl
[56] => zip
[57] => mysqli
[58] => pdo_dblib
[59] => pdo_mysql
[60] => PDO_ODBC
[61] => pdo_pgsql
[62] => pdo_sqlite
[63] => wddx
[64] => xmlreader
[65] => xmlrpc
[66] => ionCube Loader
[67] => Zend OPcache
)

cat /proc/meminfo:

MemTotal: 32891396 kB
MemFree: 2091064 kB
Buffers: 1076900 kB
Cached: 20911612 kB
SwapCached: 31220 kB
Active: 15167404 kB
Inactive: 7314512 kB
Active(anon): 489212 kB
Inactive(anon): 326900 kB
Active(file): 14678192 kB
Inactive(file): 6987612 kB
Unevictable: 12940 kB
Mlocked: 0 kB
SwapTotal: 4194300 kB
SwapFree: 4108776 kB
Dirty: 2644 kB
Writeback: 0 kB
AnonPages: 391548 kB
Mapped: 50612 kB
Shmem: 319456 kB
Slab: 7990972 kB
SReclaimable: 7586628 kB
SUnreclaim: 404344 kB
KernelStack: 8624 kB
PageTables: 31416 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 20639996 kB
Committed_AS: 4303208 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 663860 kB
VmallocChunk: 34340876504 kB
HardwareCorrupted: 0 kB
AnonHugePages: 45056 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 54272 kB
DirectMap2M: 1972224 kB
DirectMap1G: 31457280 kB

(Click to enlarge)

394184

Mentioned this to my hosting company today but no response yet. I also just purchased better hosting so hopefully that will help avoid this kind of thing. I've got loads of bespoke CDN options on this new account which look exciting but may conflict with Composr, so that will be fun to experiment with :D Hopefully I can get v11 on there, white screened on my previous account after installing :)

Ok, so I've got a fix for this coming, but first I will explain the situation. This took me some time to properly dig into.

Composr defines a bare minimum memory of 32M for PHP's memory_limit setting. It recommends 64M and actively tries to set 64M at startup.
This host seems to be imposing a limit of 40M that cannot be overridden. It 'should' work, because Composr with all non-bundled extensions works on 32M on my dev machine, but the large number of PHP extensions on your server may be causing additional memory use, or there may be other factors.

I have made some optimisations and have it working on 26M on my machine now. The main one is a cheat, if Composr detects a low memory limit then it will no longer render the admin menus so deep. That uses a relatively large amount of memory as it has to dig into all the module files to spider out the menu.

I do want to note that since 2006 PHP has had a default memory limit of 128M (https://github.com/php/php-src/commit/3ffc1c8f4a1e4c1658f94038e009e226258a65a4). a 40M limit that you cannot override is painful to see, assuming you didn't have some kind of control panel option to change that.

Note that memory limits may produce inconsistent problems, as the cache state of Composr is going to vary a lot as you go. Generally speaking, if Composr has cached stuff already then it will use less memory.

Automated response: Memory optimisation

Make a number of improvements to Composr's memory debugging ability, and optimisations to support servers with lower memory limits.