APCu requirement for 32M is checking wrong value

I have this problem, too, in Drupal 10.3

Drupal Version: 10.3.2
PHP Version: 8.3.9 - Memory limit: 4G

As others above, this error has been present through several recent updates of Drupal Core and other key modules, but always resolved after clearing caches, however since updating to D 10.3.2, it doesn't go away!

I asked my hosting company to increase this limit to 64 MG and they complied with no hesitation.

Their method was to add the following line to the document root (public_html) folder's .htaccess file.

php_value apc.shm_size 64MB

However, my Status Report still shows the same error:

PHP APCu caching
Enabled (32 MB)
Depending on your configuration, Drupal can run with a 32 MB APCu limit. However, a 32 MB APCu limit (the default) or above is recommended, especially if your site uses additional custom or contributed modules.

apc.shm_size is an INI_SYSTEM configuration value. You can’t set it in .htaccess files.

Clarify the proposed resolutions.

I have this problem as well:

PHP APCu caching

Enabled (32 MB)
Depending on your configuration, Drupal can run with a 32 MB APCu limit. However, a 32 MB APCu limit (the default) or above is recommended, especially if your site uses additional custom or contributed modules.

Small change but seems like something need test coverage for

It looks like the CI environment sets the APCu size to 3GB - whoa, that seems like a huge waste of memory, or could tests actually use that much APCu cache somehow? So, I don't think it will be easy to reproduce this exact bug there, unless there's a way for tests to modify the php config files, but we could add a test that verifies this case in test environments using the default config.

I'm getting the same warning since updating to 10.3.2. I'm using php 8.3.6. My site is hosted on Bluehost. Is there any way to eliminate this warning?

PHP APCu cachingEnabled (32 MB)
Depending on your configuration, Drupal can run with a 32 MB APCu limit. However, a 32 MB APCu limit (the default) or above is recommended, especially if your site uses additional custom or contributed modules.

Re #11 I don't know the history of why it's configured like that, but given we run dozens of tests 24 at a time on a single machine it might be necessary to prevent apcu filling up and then fragmenting. Each test will get its own unique apcu prefix and there's no way to relive all prefixed items efficiently.

Yes I can see how the APCu cache will fill up as tests are run (literally, I can see this happening locally). Although it might make sense to flush it somehow, but I guess that's easier said than done? Anyways, I added a functional test.

Is the gitlab setup reason the test-only feature could be passing?

@smustgrave yes the test-only will fail only on environments with the default php config, not the CI environment.

Cool will test locally in the morning

Although it might make sense to flush it somehow, but I guess that's easier said than done?

You can clear the entire cache, but because we run tests concurrently and tests can take anything from a few seconds to a couple of minutes each, flushing at the end of each test run would mean clearing the cache for all the other tests that are still running every few seconds. We could open an issue to see how performance and reliability looks like if we just set it a bit lower and let it fill up occasionally - went ahead and opened on here: #3467490: Investigate setting the apcu cache size lower → .

Yeah I meant flush the entries that can be flushed, pertaining to a discrete test run that is over, not flushing everything. But idk how that'd be done, since a testrunner is a cli process that doesn't have access to APCu..

1) Drupal\Tests\system\Functional\System\StatusTest::testStatusPage
Failed asserting that true is false.

Verifying test coverage locally.

Needs work for that feedback.

Alternate resolution which seems less verbose

Unless I'm missing something that will re-introduce the original multilingual bug from 🐛 Status report wrongly warns of APCu memory limit when admin language is not English Fixed ?

Back to needs review

The check and the value rendered in status report must be the same, otherwise no way to get a reason of warning

See #3142928-69: Status report wrongly warns of APCu memory limit when admin language is not English →

UPDATE: My Case was resolved via the Hosting Provider, A2 Hosting (Advanced Tech Support

Here's how:

The apc.shm_size setting can only be adjusted in system-level ini files, so I had to create a special configuration file to update the setting:

*SERVER*@az1-ls2 [~]# cat /etc/cl.php.d/alt-php83/custom.ini
apc.shm_size = 64M

https://YOURWEBSITE.net/info.php now shows 64MB of memory. Please let us know if there are any other issues we can help with.

My Status Reports no longer show the error and actually reflect the correct APCU Settings

PHP APCu available caching: Memory available: 45.48 MB.
PHP APCu caching: Enabled (64 MB)

I don't see a problem in practice with displaying ByteSizeMarkup::create($memory_info['seg_size'] * $memory_info['num_seg']) to the end user, as it's generally going to be the same as displaying ByteSizeMarkup::create(Bytes::toNumber(ini_get('apc.shm_size'))). The difference between configured size and reported size should be tiny enough that ByteSizeMarkup doesn't care.

Either way works for me, really. So if folks are adamant about displaying ByteSizeMarkup::create(Bytes::toNumber(ini_get('apc.shm_size'))), sounds good to me.

@mfb thanks for applying the suggestions. I think the result will be different if someone has more than 1 segment for APCu.

Yes I guess this was a long-standing bug, that segments weren't taken into account. I'm updating the issue summary to also mention this bug.

Actually got hit by this on a client project and the MR does fix the issue.

Committed/pushed to 11.x and cherry-picked back through to 10.3.x, thanks!

catch → closed merge request !9149

Can someone please tell me how to implement a merge request? I'm used to patches. Is this a matter of updating Drupal itself? Thanks

@rraney Introduction | Using GitLab to Contribute to Drupal →

@rraney Are you asking how to use the code changes that are in this issue before they are officially released?

I just want to know how to fix this issue @cilefen
I used the link to documentation provided by @solideogloria
It provided info on how to get a diff/patch which I applied
As for long-term fix, I assume it will be merged into future version of Drupal, correct?

Yes. Make sure you download the patch and put it in a project folder, e.g. "./patches/filename.patch". Don't use the URL for a Merge Request patch, as it can change/break over time.

@rraney That's correct. With Drupal, maintainers commit changes to supported development branches then later, release managers distribute tagged releases as new versions. Before the releases, you must patch.

@rraney this will go out with the next patch release of Drupal 10.3 which will be the first Wednesday of September.

@bas123 #27 is correct, in order to increase the memory it has to be added to the Global php.ini file, but most important, make sure you rebuild PHP-FPM or the changes will not take effect, atleast no on a cPanel system.

Regarding #27, A2 Hosting told me they could not increase the size of APCu cache on shared hosting. It is stuck at 32MB

Automatically closed - issue fixed for 2 weeks with no activity.

it's back after latest D10 update