Re: WARNING:io_submit failed due to kernel limitations MAXAIO for process=128 pending aio=127

FYI -

Found more useful information at this url:
http://www.ibm.com/developerworks/linux/library/l-async/

We are planning to increase to a reasonable upper limit and see if those
warnings go away.

*System tuning for AIO *
*
*
*The proc file system contains two virtual files that can be tuned for
asynchronous I/O performance:*
*
*
*The /proc/sys/fs/aio-nr file provides the current number of system-wide
asynchronous I/O requests.*
*The /proc/sys/fs/aio-max-nr file is the maximum number of allowable
concurrent requests. The maximum is commonly 64KB, which is adequate for
most applications*

On Wed, Jun 8, 2011 at 2:30 PM, Sanjeev M <sanjeevorcle@xxxxxxxxx> wrote:

> Hi Mark,
>
> Thanks for information about on this.
>
> We are not seeing 'async descriptor resize' wait events.
>
> Setting on our environment for this parameter is
>
> *cat /proc/sys/fs/aio-max-nr*
> *4194304*
>
> *grep  fs.aio-max-nr /etc/sysctl.conf  *
> *4194304*
>
> Nearest match that we found for this issue was in MOS support 1166003.1 has
> two workarounds for similar issue:
>
> (1) Raise the OS AIO limits such that the number of concurrent slot
> requirements never exceeds the OS limit.
>     ie: Increase AIO-MAX-NR
> OR
> (2) Disable Asynchronous IO (Set DISK_ASYNC_IO=FALSE)
>
> For 1) above We are wondering to what value this needs to be increased and
> if there is any recommendation or criteria or calculation to determine the
> same. May be this needs to be done using trial and error approach?
>
> Have asked same question in oracle SR without any luck except they are
> saying this is OS parameter and needs to be determined by unix admin.
>
> Regards,
> Sanjeev.
>
> On Wed, Jun 8, 2011 at 1:49 PM, Bobak, Mark <Mark.Bobak@xxxxxxxxxxxx>wrote:
>
>> Hi Sanjeev,
>>
>>
>>
>> Are you also seeing ‘asynch descriptor resize’ wait events?
>>
>>
>>
>> Tanel talks about this wait event, here:
>>
>>
>> http://blog.tanelpoder.com/2010/11/23/asynch-descriptor-resize-wait-event-in-oracle/
>>
>>
>>
>> As to tuning kernel parameters, well, the error itself lists MAXAIO.
>> Unfortunately, the actual tunable kernel parameter is not called ‘MAXAIO’.
>> It’s ‘fs.aio-max-nr’, and can be set in /etc/sysctl.conf.
>>
>>
>>
>> What, if anything, do you have for ‘fs.aio-max-nr’ in your
>> /etc/sysctl.conf?
>>
>>
>>
>> What does Oracle recommend for your 12.1.2 installation?  (It may be
>> different than default value for 11.1.0.7.6 database.)
>>
>>
>>
>> Looking at one of my RAC nodes, running 11.2.0.2.0, I have it set to
>> 3145728.
>>
>>
>>
>> Anyhow, hope this helps you understand a bit more about aysnch I/O, the
>> MAXAIO limit, and the ‘asynch descriptor resize’ wait event.
>>
>>
>>
>> -Mark
>>
>>
>>
>> PS  There’s also MOS Doc ID 1081977.1, which Tanel mentions in his blog
>> entry, but, there’s not much info there.
>>
>>
>>
>> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
>> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Sanjeev M
>> *Sent:* Wednesday, June 08, 2011 4:31 PM
>> *To:* ORACLE-L
>> *Subject:* WARNING:io_submit failed due to kernel limitations MAXAIO for
>> process=128 pending aio=127
>>
>>
>>
>> Gurus,
>>
>>
>>
>> We have recently moved from Solaris to Linux for our 12.1.2 E-business
>> suite environment, RDBMS(11.1.0.7.6), GRID/ASM(11.2.0.2) and are observing
>> following warnings in rdbms trace files:
>>
>>
>>
>> WARNING:io_submit failed due to kernel limitations MAXAIO for process=128
>> pending aio=127
>>
>>
>>
>> Noticed that the module information in the trace files varies from job
>> queue process,parallel query slave and httpd sessions.
>>
>>
>>
>> Did search for this error in MOS and got few hits but did not have an
>> exact match of our situation, raised SR with oracle support.
>>
>>
>>
>> Have any of you guys encountered these warnings and know what OS parameter
>> to change to fix this and any recommendation or criteria for setting value
>> for maxaio.
>>
>>
>>
>> disk_asynch_io has been set to TRUE.
>>
>>
>>
>> Regards,
>>
>> Sanjeev.
>>
>
>

Other related posts: