itsgoingd / itsgoingd/clockwork

Memory exhaustion when trying to fread the index.

Open
#749 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
PHP
Stars
6k
Forks
333
Avg merge
5m
Merged PRs (30d)
1

Description

Hi,

First, I think this is related to #747.

I've been using Clockwork on a development app that I've been playing around with for a year or so. The app is a bit of a passion project, so thankfully this didn't happen in production. I'm currently testing extremely large media uploads and processing them. I'm trying to nail down 2-20+GB 4K UHD file uploads.

When testing last night I started receiving this error on every request:

Allowed memory size of 1073741824 bytes exhausted (tried to allocate 1242655144 bytes) at /vendor/itsgoingd/clockwork/Clockwork/Storage/FileStorage.php:256)

This is related to this line:

                $trimmed = $trimmedLength > 0 ? fread($this->indexHandle, $trimmedLength) : '';

I turned off debug mode, but because Clockwork was still enabled, it continued to occur.

So I figured at this point that it's related to the index file just being too large to fread, and I decided to investigate the clockwork storage folder:

du -sh clockwork
304G clockwork

Woops. At 304GB, I had a feeling something was truly off. I haven't come close to exhausting my local system's storage, so I just didn't notice this 300+GB folder (the storage folder is also larger than that, because I'm testing these massive uploads.)

Looking at the clockwork/index file:

1302535836 Oct 15 11:36 clockwork/index

It's absolutely massive, at 1.3GB. I figure this isn't normal. For reference, I set PHP to 1GB of memory, but it looks like it's actually using 1073MB.

I imagine that because I'm uploading large files through Laravel, that must be the reason why Clockwork has such a large storage directory. I don't mind it being large, but I think it's been recording data since I very first started using it, and that was over a year ago.

In looking at #747, I saw that there was a configuration declaration CLOCKWORK_STORAGE_EXPIRATION but I can't see anything in the documentation about this. Based on the comment in that thread though, it seems to be set to minutes, so I am going to try 40000+, since I figure a month or so is enough data to retain.

According to a different repo comment (https://github.com/ppy/osu-web/issues/8420#issuecomment-1019808827) this is set by default to 1 week for them.

Is there a default set for Clockwork?

Did my system not honor that default?

I don't want to lose all the data, so I'm going to try and delete files older than 30 days. Hopefully that works.

If you have any suggestions, let me know, and I hope this helps the probably one other person this might happen to.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at Clockwork/Storage/FileStorage.php:256 and inspect how the index is read and trimmed. Trace the CLOCKWORK_STORAGE_EXPIRATION configuration and its default, then reproduce with a large index or retained storage. Done should mean expiration behavior is verified and large indexes no longer cause memory exhaustion, with the configuration behavior documented if needed.

Written by the indexing model from the issue text.

Assessment

Tech stack
laravel, php
Domain
backend, devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.