Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60443 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49621 invoked from network); 4 May 2012 09:28:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 May 2012 09:28:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=julienpauli@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=julienpauli@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender) X-PHP-List-Original-Sender: julienpauli@gmail.com X-Host-Fingerprint: 209.85.215.170 mail-ey0-f170.google.com Received: from [209.85.215.170] ([209.85.215.170:37262] helo=mail-ey0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0C/61-38082-E11A3AF4 for ; Fri, 04 May 2012 05:27:59 -0400 Received: by eaao10 with SMTP id o10so696001eaa.29 for ; Fri, 04 May 2012 02:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=oLMVOwkiuIRYeJJwdFg5g9ZJo/UuDfZnW41kBfaTXxw=; b=CQXZYuhZq3/yQDXQg9oQGcGHf/7CAgXGjB87ON9G0n4VnyZY1qqPT5cB5DISBCjOK7 iOBzEApO11kmBi5x70t/zX/NoQaQHqOUDKDrgeBjdo6OE0NNHyvE+WnWOiobD1QFuc53 gwxAwAgEuJeeAVJlkxtNXHw2A1TPRroFUajaloF7uux7b56aGosOu76TR0HiYKwKRbiJ XrxiI7Ll7lUJSZIa1v5fZ8+E+v0Mj7Zb2GpEpM2+62NMxVL/sHPoHIoYMTdgwh6y47SW pReIveSc8eQTxyYmerjma+lHqLVRHE10Po5qth9iQafUfHJaYTjlBYkz8gxboT2BbyPI ghxQ== Received: by 10.213.20.212 with SMTP id g20mr1028528ebb.62.1336123676298; Fri, 04 May 2012 02:27:56 -0700 (PDT) MIME-Version: 1.0 Sender: julienpauli@gmail.com Received: by 10.213.29.83 with HTTP; Fri, 4 May 2012 02:27:15 -0700 (PDT) In-Reply-To: References: <4F9E2173.50005@garfieldtech.com> <000e01cd269a$06f15230$14d3f690$@php.net> <002701cd26b5$1cd0bb70$56723250$@thetaphi.de> <4F9EC8B4.3040600@garfieldtech.com> <4F9F4208.7020106@garfieldtech.com> <4FA01214.5030606@garfieldtech.com> Date: Fri, 4 May 2012 11:27:15 +0200 X-Google-Sender-Auth: ZUmpPXQ2xQ2NPTceAsvoebvBOek Message-ID: To: Paul Reinheimer Cc: internals@lists.php.net, Larry Garfield Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] readfile() memory usage From: jpauli@php.net (jpauli) On Tue, May 1, 2012 at 8:44 PM, Paul Reinheimer wro= te: > Hi, > >> It sounds like it. =A0In that case the memory spike is happening in the = output >> buffer, where the file is streamed into by readfile() in 8K chunks until= the >> output buffer explodes. :-) >> >> So, I think we're back to "urban legend" territory. > > > That's good to know. Thanks, and my apologies for adding confusion to the= issue. > > One question, with a value of 4096 for the ini directive, shouldn't it > be flushing data to the client long before I run into memory issues? > What have I missed here. > That's an interesting catch, and the answer is here :http://lxr.php.net/opengrok/xref/PHP_5_3/main/output.c#596 In fact, even if your ob layer is , say , 4K length, PHP will reallocate it to fit the data written in it (http://lxr.php.net/opengrok/xref/PHP_5_3/main/output.c#395) with a block_size step (http://lxr.php.net/opengrok/xref/PHP_5_3/main/output.c#402) In short, having an output_buffer of, say, 4K lenght, will not prevent PHP to allocate several Mb of data if the OB layer gets suddenly fed with such amount of data, what readfile() with MMAP strategy does actually. Mike could help as he's the main ob layer designer. Bye :) Julien.Pauli