Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88623 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55970 invoked from network); 1 Oct 2015 20:39:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Oct 2015 20:39:05 -0000 Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:55101] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3F/55-26330-6E99D065 for ; Thu, 01 Oct 2015 16:39:03 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id 7A0946D2039; Thu, 1 Oct 2015 22:38:59 +0200 (CEST) Received: from w530phpdev (pD9FD2EF3.dip0.t-ipconnect.de [217.253.46.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by h1123647.serverkompetenz.net (Postfix) with ESMTPSA id F3EF46D2002; Thu, 1 Oct 2015 22:38:53 +0200 (CEST) To: "'Dmitry Stogov'" , "'Matt Ficken'" Cc: "'Pierre Joye'" , "'Anatoliy Belsky'" , "'Laruence'" , "'PHP Internals'" , References: In-Reply-To: Date: Thu, 1 Oct 2015 22:38:50 +0200 Message-ID: <024e01d0fc89$31005990$93010cb0$@belski.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHEZydHUDlzPZMYkUAa9TBZ2Cu8iQH1cSltAgxS6RICvBKMXgJg6u78Alds+IoBNSLbHgFWewTNAfDhgDUDBDbNGp3X6+fA Content-Language: en-us Subject: RE: [PHP-DEV] Re: Windows OpCache bug fix From: anatol.php@belski.net ("Anatol Belski") Hi, > -----Original Message----- > From: Dmitry Stogov [mailto:dmitry@zend.com] > Sent: Thursday, October 1, 2015 12:20 PM > To: Matt Ficken > Cc: Pierre Joye ; Anatoliy Belsky ; > Laruence ; PHP Internals ; > dmitry@php.net > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix >=20 > On Thu, Oct 1, 2015 at 11:54 AM, Matt Ficken > wrote: >=20 > > > >> And what wincache does. It is slower but the request is served. > >> > >> > >> WinCache (file cache) if it can't reattach, creates a new shared = mem > >> file > > for just that process: see > > = http://svn.php.net/viewvc/pecl/wincache/trunk/wincache_filemap.c?revis > > ion=3D336846&view=3Dmarkup > > Line 1122. > > >=20 > I'm not sure how WinCache works, but opcache already implements most > necessary functionality. Actually we should just: > 1) If process can't map SHM - lets map it into different address and = disable > default SHM (ZCG(accel_directives.file_cache_only)=3D1) > 2) extended file_cache may look into improperly mapped segment before > reading it from file. > But ff course this is more difficult. >=20 >=20 > > > > Yes, ideally it would be position independent, maybe using based > > pointers for the structs in zend_smm_shared_globals, > > zend_accel_shared_globals, etc.... > > > > I agree my bugfix is suboptimal but its the least complex option to > > get it fixed for users in 7, so their requests get served. > > > > > > My bugfix would increase memory usage, but so does a 2nd WinCache(or = 3rd). > > But at least if the 2nd OpCache is shared (the same procedure as if = no > > OpCache existed) its less likely to create a 3rd OpCache. For me at > > least, often several processes in a row have this issue, so could = have > > a 3rd or 4th OpCache or WinCache(even more memory), possibly very = quickly. > > >=20 > Your proposal is better than WinCache. >=20 >=20 > > > > Creating a 2nd OpCache, if its shared or per-process (like WinCache) > > seems to be the simpler workaround. The trade-off is = memory(especially > > if per-process), time to recompile scripts, and sometimes breaking > > opcache_reset(), opcache_invalidate() and stat cache pages(shared or > > per-process OpCache). > > >=20 > This may break application logic. In worst case different SHM may keep = different > versons of the same script... >=20 >=20 > > > > Using the file cache should be better(won't slow down to recompile > > scripts). But would still either require changing > > zend_shared_alloc_startup() and other places because = create_segments() > > would still be returning ALLOC_FAILURE, OR creating a 2nd shared or > > per-process OpCache anyway. Is this likely to be done? That would be > > great, but it seems less likely because of the complexity. > > >=20 > This may be changed in some way. >=20 >=20 > > > > Up to 6 OpCaches(5 backups) may be way too many (based off > > map_retries, 25 may be too many). My testing only ever gets a 2nd > > OpCache(never got a 3rd, etc...). > > >=20 > 6 may be not enough anyway. If we have a limit it's going to be = exceeded. > MS will improve their ASLR once again... :) >=20 >=20 > > There should be a workaround/suboptimal fix at least until someday > > when the optimal solution is done, so requests get served. > > >=20 > In my experience, temporary incomplete solutions are almost never = replaced > with general ones. > New and new incomplete fixes are added on top instead. > Anyway Anatol, if you have time, can you please play with patch and = give your > opinion. >=20 Yeah, I'll be testing that as well anyway, now that RC4 is out. I was = intended also to do some synthetic tests, because seems some (especially = 32-bit) environments are affected more than others. Namely, I'm trying = hard to get this issue on 64-bit with no chance. IMHO creating the sidestep caches looks not convincing. From the issues = mentioned, like different cached script versions, but also indeed taking = away the control over memory limit, etc. Even one would decide for that, = the other mentioned parts would need to be fixed. Is that something = achievable to fix in the current state? Dmitry, I'd have a question to this > Also. if we can't map SHM into desired address space, we may map it in = any > other address and copy data into the process memory similar to = file-cache. In randomized memory layout, even the base were available and = OpenFileMapping were worky, some parts of that memory were already = taken. How exactly it could be done, could you please give a couple of = pointers to this? Would the file cache be always required then? Regards Anatol