static:warm never ends?

[stephenmeehanuk]

Bug description

I've noticed that php please static:warm --queue isn't stopping?

I'm the only user logged in, and I'm not making any edits to entires. I'm checking the progress of the static:warm command by visiting /cp/utilities/cache and pressing refresh.

When the page count gets to around 500, I've noticed he page count drops? and the static:warm keeps on running?

I've been keeping an eye on this for a couple of hours and it keeps on doing the same thing.

This is my deploy script

php artisan cache:clear
php artisan config:cache
php artisan route:cache
php artisan statamic:stache:warm
php artisan statamic:search:update --all
php artisan statamic:static:clear
php please static:warm --queue

Is this perhaps related to another issue I'm seeing with invalidating cache on save? When I edit an entry and press save, the cache never clears? Maybe the invalidation job is never done because the static:warm never finishes?

These are my queue settings in Ploi. As you can see there's plenty of memory assigned to the queue worker.

How to reproduce

Seems like an issue with this website only, as the same site (same settings) running on a staging subdomain doesn't have any of these issues.

Logs

No response

Environment

Environment
Application Name: Website Name
Laravel Version: 10.48.4
PHP Version: 8.2.12
Composer Version: 2.7.2
Environment: production
Debug Mode: OFF
URL: website.com
Maintenance Mode: OFF

Cache
Config: CACHED
Events: NOT CACHED
Routes: CACHED
Views: CACHED

Drivers
Broadcasting: pusher
Cache: redis
Database: mysql
Logs: stack / single
Mail: log
Queue: redis
Session: redis

Livewire
Livewire: v3.4.9

Statamic
Addons: 6
Antlers: runtime
Sites: 1
Stache Watcher: Disabled
Static Caching: half
Version: 4.55.0 PRO

Statamic Addons
jacksleight/statamic-bard-mutator: 2.3.0
jonassiewertsen/statamic-jobs: 1.4.0
jonassiewertsen/statamic-live-search: 2.0.1
jonassiewertsen/statamic-livewire: 3.2.0
statamic/collaboration: 0.8.1
teamnovu/statamic-images-missing-alt: 1.0.2

Installation

Fresh statamic/statamic site via CLI

Antlers Parser

Runtime (default)

Additional details

No response

[stephenmeehanuk]

The short video below shows the issue. Page cache shows 511, press refresh and it drops to 497?

https://github.com/statamic/cms/assets/72254741/349c4ade-2c6c-4cd0-bf20-a9992d922939

Statamic\Console\Commands\StaticWarmJob never seems to stop?

[jeremyvienney]

Did you check your opcache settings ? If it is enabled it might be related. I just succeed to understand a big issue that I had for years with static cache invalidation & redis due to opcache memory. I set minimum 4Go for opcache memory maximum settings for others keys, it solve all my issues.

[stephenmeehanuk]

Thanks for the reply

Where do you configure opcache settings?

According to Ploi, I don't have it enabled?

But in /cp/utilities/phpinfo it says it's up and running?

[stephenmeehanuk]

My sites.php uses env('APP_URL')

'sites' => [

        'default' => [
            'name' => config('app.name'),
            'locale' => 'en_US',
            'url' => env('APP_URL'),
        ],

    ],

But according this post the way to do it, is to use config('app.url')

Is there any difference?

'sites' => [
    'default' => [
        'name' => 'My Site',
        'locale' => 'en_US',
-       'url' => '/',
+       'url' => 'https://mysite.com/', // or config('app.url')
    ],
],

[jeremyvienney]

Don't know about Ploi settings but I think it would enable a opcache config for the current nginx user/group. As the phpInfo values, opcache is enabled, so you can ssh to your server and check the default values, I recommend you to install this on your server to help you check the health of opcache https://github.com/amnuts/opcache-gui

[jeremyvienney]

My sites.php uses env('APP_URL')

'sites' => [

        'default' => [
            'name' => config('app.name'),
            'locale' => 'en_US',
            'url' => env('APP_URL'),
        ],

    ],

But according this post the way to do it, is to use config('app.url')

Is there any difference?

'sites' => [
    'default' => [
        'name' => 'My Site',
        'locale' => 'en_US',
-       'url' => '/',
+       'url' => 'https://mysite.com/', // or config('app.url')
    ],
],

Mine is relative with a slash only and work fine. Maybe you enter in a loop where a specific url cannot resolve correctly the relative url, or maybe a custom route defined in Laravel web.php file, you could try full absolute URL instead and see if it solve your issue !

[Cannonb4ll]

Hi everyone! 👋

Just wanted to chime in on the OPcache situation and ploi.io. Generally, CLI does not have OPcache enabled, at least, Ploi doesn't enable that. It only enables it for FPM (so web requests).

The insight telling you OPcache isn't enabled, is for FPM (I might need to make that more clear on our end). You can easily 1-click enable OPcache inside the PHP tab. If you do that, the insight will disappear automatically (especially if you use the fix it for me button)

When you're working with queues, you're working with CLI (and not FPM). So what you're seeing in the UI of Statamic is the status of the FPM settings, not CLI settings. Obviously, you can enable OPcache for CLI but I don't really see the optimized benefit of that.

(Thanks Sam for notifying me 🥰)

[stephenmeehanuk]

It's working now 🙂

I think the problem was a handful of things

• The queue was bigger than I thought
• The queue worker didn't have enough memory
• I was running a scheduled job once a day

I think the once a day scheduled job was overloading the queue worker, as it didn't have enough memory to complete the tasks.

The website uses a lot of glide image presets (about 100). I suspect this is what was clogging up the queue.

I've since upped the queue worker memory from 1024mb to 3072mb and left it to run overnight.

There is now 152302 cached images (5.86 GB) this is an increase of about 2000

I've removed the daily cron job, it's not required now the cache invalidation is working. And because the queue worker is working, git commits are being pushed as expected.

I'll keep an eye on it, but it seems to be working as expected now.

[duncanmcclean]

Thanks for providing more info! I'll close this issue now.