RE: Tuned service on Linux

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Sun, 11 Feb 2024 10:10:09 -0500
Message-ID: <53bc01da5cfc$680f2d30$382d8790$_at_rsiz.com>

It appears to change 3 parameters and not make one change because something similar is already configured.  

From a theoretical point of view the definitions and roles of those three parameters should be considered from a point of view of what the changes in value could possibly change in performance. One of them is just an extension by one of the port range, so that is unlikely to change performance. Possibly it is to reserved that additional port one beyond the default range for a performance tool to talk through (or it could be part of a security issue I can only guess at.)  

For the other two, here are the definitions:  

dirty_ratio

Defines a percentage value. Writeout of dirty data begins (via pdflush) when dirty data comprises this percentage of total system memory. The default value is 20.

Red Hat recommends a slightly lower value of 15 for database workloads.

dirty_background_ratio

Defines a percentage value. Writeout of dirty data begins in the background (via pdflush) when dirty data comprises this percentage of total memory. The default value is 10. For database workloads, Red Hat recommends a lower value of 3.

2024-02-10 13:15:06,175 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'vm.dirty_background_ratio' from '3' to '5'
2024-02-10 13:15:06,175 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'vm.dirty_ratio' from '40' to '10'
 

(Mladen probably already knew that)  

IF these are the only things being changed, then to convert the theory of these changes into performance evaluation you would first look at whether you ever bump into a free clean memory delay. If not, then they have not mattered.  

But that would be for a particular snap of time on a particular running machine.  

I think what you are really asking is whether making this run is worth the trouble. Probably it is. Consider that someone else may have a cookbook for highly interactive use of a plagiarized definition reimplementation of UNIX system set-up. They hand that system to you to run Oracle on, and without looking it may have “insane” values for running Oracle. When you do this exercise, you end up with “sane” values for running Oracle. Of course someone may have set things up knowing the exact hardware and your planned use and put prognostically “optimal” values in place. There is some possibility that those values would be overridden to merely “sane” and not be as good. But I *think* you will always get “sane” values for Oracle this way and that any variation from “optimal” overall probably makes little difference.  

But I’m not really sure. To test, I think you would been a re-playable significant load near peak utilization of the hardware and run it twice.  

There was a time when hardware was expensive enough and the maximum throughput of systems that could be built was close enough to the works/doesn’t work boundary that this was a consulting expense payback to the consumer that justified getting it “just right.” No one has paid me to make their machine spin everything as close to optimally as possible in a long time. “How the heck did you do that?” from the machine vendor is a dimming echo from long ago.  

Once in a while the load was near optimal SQL, so it really was the way to get things to work fast enough, particularly with i/o to “spinning rust” and/or just trying to run too many things simultaneously.  

It was fun while it lasted.  

Sorry I don’t have a better answer for you, old friend.  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Andrew Kerber Sent: Saturday, February 10, 2024 5:21 PM To: gogala.mladen_at_gmail.com
Cc: ORACLE-L
Subject: Re: Tuned service on Linux  

I haven’t gone to the trouble of benchmarking, but I consider it a useful way to make sure all the environments are set up consistently.      

Sent from my iPad

On Feb 10, 2024, at 12:37, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:



I have been using the "tuned" service since its inception in the late versions of OL7. The service is up:  

[oracle_at_ora21c tuned]$ systemctl status tuned
● tuned.service - Dynamic System Tuning Daemon

   Loaded: loaded (/usr/lib/systemd/system/tuned.service; enabled; vendor prese>
   Active: active (running) since Sat 2024-02-10 13:15:06 EST; 3min 37s ago
     Docs: man:tuned(8)
           man:tuned.conf(5)
           man:tuned-adm(8)
 Main PID: 1056 (tuned)
    Tasks: 6 (limit: 100264)

   Memory: 19.2M
   CGroup: /system.slice/tuned.service

           └─1056 /usr/libexec/platform-python -Es /usr/sbin/tuned -l -P  

Feb 10 13:15:05 ora21c.home.com systemd[1]: Starting Dynamic System Tuning Daemon Feb 10 13:15:06 ora21c.home.com systemd[1]: Started Dynamic System Tuning Daemon  

I also make sure that the oracle plugin is installed and turned into the active profile:  

[oracle_at_ora21c tuned]$ tuned-adm active
Current active profile: oracle  

When I check the log, it changes a lot of parameters:  

parameter 'vm.dirty_ratio' from '40' to '10'

2024-02-10 13:15:06,175 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'vm.dirty_background_ratio' from '3' to '5'
2024-02-10 13:15:06,175 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'vm.dirty_ratio' from '40' to '10'
2024-02-10 13:15:06,176 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'net.ipv4.ip_local_port_range' from '9000 65499' to '9000 65500'
2024-02-10 13:15:06,194 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'vm.dirty_background_ratio' from '3' to '5'
2024-02-10 13:15:06,194 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'vm.dirty_ratio' from '40' to '10'
2024-02-10 13:15:06,199 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'net.ipv4.ip_local_port_range' from '9000 65499' to '9000 65500'
2024-02-10 13:15:06,218 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'vm.dirty_background_ratio' from '3' to '5'
2024-02-10 13:15:06,218 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'vm.dirty_ratio' from '40' to '10'
2024-02-10 13:15:06,219 INFO     tuned.plugins.plugin_sysctl: Overriding sysctl parameter 'net.ipv4.ip_local_port_range' from '9000 65499' to '9000 65500'
2024-02-10 13:15:06,300 INFO     tuned.plugins.plugin_vm: transparent_hugepage is already set in kernel boot cmdline, ignoring value from profile
2024-02-10 13:15:06,300 INFO     tuned.daemon.daemon: static tuning from profile 'oracle' applied
 

However, I don't see any particular benefits from it. Can anyone share any benefits realized by setting this "tuned" thingy up? Is that just another religious ritual we perform in vain hope that the applications running on that database will run faster? I guess that the only way would be to run SLOB with and without the "tuned" service but I am too lazy for that right now.  

-- 

Mladen Gogala

Database SME

https://dbwhisperer.wordpress.com

 





--
http://www.freelists.org/webpage/oracle-l

Received on Sun Feb 11 2024 - 16:10:09 CET