Opened 4 years ago

Closed 2 years ago

#255 closed defect (fixed)

multiple caches of same file and file modification

Reported by: bigbug Owned by: moo
Priority: major Milestone: 2.0.1
Component: cacher Version: 1.3.1
Keywords: Cc:
Application: PHP Version: 5.2.14
Other Exts: SAPI: FastCGI
Probability: Rare Blocked By:
Blocking:

Description

I have found that sometimes when i modify file on high-load servers the opcode not updated for some threads.

So i have:
xcache.count="8"
xcache.stat="On"
in my config.

The same file sometimes appear not only in one php# cache block, but in many of them. And when i modify such file, it is updated only in one of caches, others still execute the old cache opcode.

Workaround is to set xcache.count="1", then it appears only one time in only one cache ;)

Change History (13)

comment:1 Changed 4 years ago by moo

it's normal to "see" new and old file spawn in different cache slot, because they're not the same inode. however it's not good if you're sure it's executing the "old" code. are you sure all file that got updated is always the most newest in mtime? it could be inode recycle issue with mtime

can u pls upgrade to 1.3.1

comment:2 Changed 4 years ago by bigbug

Yes, i'm sure that the old opcode is executed (while new one shows in different slot). I'm sure the file gets newer mtime (i have checked that).

If i update mtime of such file again - sometimes that fixes the problem, sometimes - no.

I'm not sure that the new file appears into the newest cache slot, will try to check.

PHP is executed as fastcgi daemon (no php-fpm or such, but the php is patched to have much bigger backlog).

ok, will upgrade to the 1.3.1 in 20mins, and if such situation re-appear again will post.

comment:3 Changed 4 years ago by bigbug

btw, on the lower load servers haven't seen such error.

comment:4 Changed 4 years ago by bigbug

  • Version changed from 1.3.0 to 1.3.1

Eghmh, now i have such error with count=1 ;/ and same file appears 7 times in one list ;/

comment:5 Changed 4 years ago by moo

same file path listed multiple times is fine because the inode is different

comment:6 Changed 4 years ago by bigbug

but executing the old code is not ok, right? I have stat=on

comment:7 Changed 4 years ago by moo

even old files is listed there, it won't be executed, it's just a piece of garbage not collected yet

when it does execute, there is something wrong there, but i don't have a glue

do you have "new" files that is exactly same last-modified-time and size as the old file (even different name)? in this rare case it would hit the wrong file

comment:8 Changed 4 years ago by bigbug

No, the new files only gets same name, no same mtime or size.

filesystem is ext4, mounted with noatime.

comment:9 Changed 4 years ago by bigbug

Just mentioned, i have xcache.test set to on, maybe that is the reason? (btw can't find what that option mean).

Set it to off, will report tomorrow.

comment:10 Changed 4 years ago by bigbug

Same thing hit again.

The new file get cached with new inode, but the old code (old "hits" is increasing) is executing.

comment:11 Changed 4 years ago by moo

        if (xc_entry_equal_dmz(xce, p)) { <- if inode same
            if (p->type == XC_TYPE_VAR || /* PHP */ (p->data.php->mtime == xce->data.php->mtime && p->data.php->sourcesize == xce->data.php->sourcesize)) { <- and only if both mtime/filesize is same
                p->hits ++; // it's hit
                p->atime = XG(request_time);
                return p; // found, return, restore it
            }

does this remind you any thing? i'm not sure why it still happen

comment:12 Changed 4 years ago by bigbug

Partition is mounter with atime off. New file 100% gets different size and different mtime.

comment:13 Changed 2 years ago by moo

  • Milestone set to 2.0.1
  • Resolution set to fixed
  • Status changed from new to closed

this is fixed perfectly in 2.0.1. see bug #284

Note: See TracTickets for help on using tickets.