Sponsored Content
Full Discussion: The immortal aioserver
Operating Systems AIX The immortal aioserver Post 302958331 by bakunin on Wednesday 21st of October 2015 10:29:56 AM
Old 10-21-2015
Quote:
Originally Posted by agent.kgb
if you want to see them dead, try to change some parameters in the system ;-)
While this is very true - in fact, the "aio" stands for "Asynchronous I/O" and the processes are controlled by tuning parameters - it is most probably a bad idea to do so on a database system. If memory serves correctly Oracle always requested to have asynchronous I/o switched on during the installation and the performance of the db-writer process greatly suffered when it was switched off.

Anyways, the "aioserver" processes are definitely not reponsible for preventing the unmount of the filesystems, so it won't have any positive effect even if it succeeds (although this, given that they are kernel processes is highly unlikely).

The number, btw., of the main processes is dependent on the number of LCPUs the system has. I suppose your system has 8 CPUs configured and this is why you always see a minimum of 8 processes running.

I hope this helps understanding these processes.

bakunin
 

2 More Discussions You Might Find Interesting

1. AIX

AIOServer process question

Hi I've been trying to learn a bit more about AIOServer processes and how my company administers them, one question i have is, while checking, most of my servers show a memory overhead of about 448 k per aioserver process (nmon -A) however i have found a few with figures of 67 or 56k. Most... (0 Replies)
Discussion started by: philib
0 Replies

2. AIX

aioserver query

Hi Gurus, What is the recommended value for aioserver in aix 5.3 current value is 16384 And used is ps -k|wc -l 4768 We usauslly get issues like slow server performance and query waiting time more etc. Regards newaix (2 Replies)
Discussion started by: newaix
2 Replies
aio_proc_max(5) 						File Formats Manual						   aio_proc_max(5)

NAME
aio_proc_max - maximum number of async I/O operations that can be queued by any process that uses aio_reap() VALUES
Failsafe Default Allowed values Recommended values DESCRIPTION
This tunable places a limit on the system resources that can be consumed by processes that use aio_reap(2). The limit is enforced at a per-process level to improve scalability as the number of CPUs and processes increases. When this tunable is set to 0, it has no effect. That is, resource usage will be restricted by the other limits provided on HP-UX. (These include and setrlimit(2) with Use of these limits (while keeping at 0) ensures compatibility with POSIX standards and legacy applications. However, most of these other limits are enforced at the system-wide level, and they can in some cases reduce scalability. To solve this problem when compatibility with the other limits is not required, the tunable can be set. When is set to a positive value, it becomes the only tunable limit enforced for processes that use aio_reap(2). Memory-usage limits (e.g. or will NOT be enforced for aio_reap(2) processes when is set. However, processes that use POSIX AIO without aio_reap(2) (i.e. only using standard POSIX interface calls) will continue to have all of the old limits enforced. For sysadmins wishing to obtain the increased scalability of without giving up control of memory limits, the tunable can be set. That tun- able limits the size of each I/O, effectively constraining the total memory usage of all processes that use aio_reap(2) by the quantity: This approach provides full control of system-wide resource usage without depending on explicit system-wide constraints. Note: when is set, processes that use aio_reap(2) can still set process-specific limits with the limit. The minimum of and will be the value that is enforced by the AIO subsystem. However, ALL other rlimits related to AIO will have no effect (i.e. will not be enforced) for aio_reap(2) users when is non-zero. Who Is Expected to Change This Tunable? System administrators that run applications requiring heavy usage of AIO (with aio_reap(2)) to disks or filesystems. Restrictions on Changing This tunable is dynamic. Changes to to this tunable take effect immediately for new processes started after the change. But they do not impact existing running processes. (That is, any process running at the time of tuning will be "grandfathered" in, and will adhere to the value held by this tunable at the time the process was started) When Should the Value of This Tunable Be Raised? should be raised for applications that make heavy usage of AIO with aio_reap(2). What Are the Side Effects of Raising the Value of This Tunable? When raising this tunable from its default of 0 to a positive value, the effects described above will take place. (see However, once this tunable is a positive value, the only effect of raising it further is that more system resources can be used for asynchronous I/Os. When Should the Value of This Tunable Be Lowered? should be lowered when AIO performance is acceptable but there is concern about too many system resources being devoted to AIO. What Are the Side Effects of Lowering the Value of This Tunable? As long as it remains a positive value, lowering the value of this tunable simply decreases the number of I/Os that each process can issue. When this tunable is set to 0, it will cease to have an effect, and the system will enforce only the old system-wide tunables described above (see What Other Tunables Should Be Changed at the Same Time as This One? No additional tunables need to be changed at the same time as this one. However, can optionally be set if there is an interest in limiting memory usage for AIO. In addition, when is set to a positive value, another option is to lower the values of the older system wide limits (such as and This is useful because the older limits will have no impact on aio_reap(2) users, and aio_reap(2) users are expected to consume the majority of system resources. (Leaving less resources for processes governed by the older limits) WARNINGS
All HP-UX kernel tunable parameters are release specific. This parameter may be removed or have its meaning changed in future releases of HP-UX. Installation of optional kernel software, from HP or other vendors, may cause changes to tunable parameter values. After installation, some tunable parameters may no longer be at the default or recommended values. For information about the effects of installation on tun- able values, consult the documentation for the kernel software being installed. For information about optional kernel software that was factory installed on your system, see at AUTHOR
was developed by HP. SEE ALSO
kctune(1M), sam(1M), aio_reap(2), gettune(2), settune(2), setrlimit(2), aio(5), aio_iosize_max(5). aio_max_ops(5), aio_physmem_pct(5). Tunable Kernel Parameters aio_proc_max(5)
All times are GMT -4. The time now is 02:33 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy