Hi!
"Panayot" == Panayot Belchev <panayot@panayot.com> writes:
Panayot> Hi, Panayot> I just noticed that all our MariaDB 5.2 servers show the same: Panayot> $ ps -eo ni,comm |grep mysql Panayot> 9 mysqld_safe Panayot> 19 mysql_isam_spac <defunct> Panayot> 19 mysqld I digged a bit deeper into this Panayot> While servers with Oracle MySQL are at nice -n 0 pthread_setschedparam() uses sched_getscheduler() to set the priority. It's called with pthread_setschedparam(thread, POLICY, &sp), where POLICY == SCHED_OTHER
From 'man sched_setscheduler'
Scheduling Policies The scheduler is the kernel component that decides which runnable process will be executed by the CPU next. Each process has an associ ated scheduling policy and a static scheduling priority, sched_prior ity; these are the settings that are modified by sched_setscheduler(). The scheduler makes it decisions based on knowledge of the scheduling policy and static priority of all processes on the system. For processes scheduled under one of the normal scheduling policies (SCHED_OTHER, SCHED_IDLE, SCHED_BATCH), sched_priority is not used in scheduling decisions (it must be specified as 0). As you are calling this with sched_priority <> 0, pthread_setschedparam() will return EINVAL which has the effect that pth_min_priority and pth_max_priority are always 0, which casues xt_p_set_low_priority() to misbehave. This is at least the case on SuSE 11.4 and Linux 2.6.37.6-0.5. Regards, Monty