Re: Improvement of checkpoint IO scheduler for stable transaction responses
От | KONDO Mitsumasa |
---|---|
Тема | Re: Improvement of checkpoint IO scheduler for stable transaction responses |
Дата | |
Msg-id | 51DA7C21.5090106@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Improvement of checkpoint IO scheduler for stable transaction responses (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>) |
Ответы |
Re: Improvement of checkpoint IO scheduler for stable transaction
responses
|
Список | pgsql-hackers |
I create fsync v2 patch. There's not much time, so I try to focus fsync patch in this commit festa as adviced by Heikki. And I'm sorry that it is not good that diverging from main discussion in this commit festa... Of course, I continue to try another improvement. * Changes - Add ckpt_flag in mdsync() etc with reference by Heikki's patch. It will be more controllable mdsync() in checkpoint. - Too long sleep in fsync phase is not good for checkpoint schedule. So I set limited sleep time which is always less than 10 seconds(MAX_FSYNC_SLEEP). I think that 10 seconds sleep time is a suitable value in various situations. And I also considered limited sleep time by checkpoint progress, however, I thought md.c should be simple and remain robust. So I have remained simple. - Maximum checkpoint_fsync_sleep_ratio in guc.c is changed 1 to 2. Because I set limited sleep time 10 secounds. We can more flexibly change it and be more safety. And I considered abbreviation of parameters in my fsync patch. * checkpoint_fsync_delay_threshold In general, I think that it is suitable about 1 second in various environments. If we want to adjust sleep time in fsync phase, we can change checkpoint_fsync_sleep_ratio. * checkpoint_fsync_sleep_ratio I don't want to omit this parameter, because it can only regulate sleep time in fsync phase and checkpoint time. * Benchmark Result(DBT-2) | NOTPM Average 90%tile Maximum ------------------------+---------------------------------------- original_0.7 (baseline) | 3610.42 4.556 10.9180 23.1326 fsync v1 | 3685.51 4.036 9.2017 17.5594 fsync v2 | 3748.80 3.562 8.1871 17.5101 I'm not sure about this result. Fsync v2 patch was too good. Of cource I didn't do anything in executing benchmark. Please see checkpoint_time.txt which is written detail checkpoint in each checkpoint. Fsync v2 patch seems to be short in each checkpoint time. * Benchmark Setting [postgresql.conf] archive_mode = on archive_command = '/bin/cp %p /pgdata/pgarch/arc_dbt2/%f' synchronous_commit = on max_connections = 300 shared_buffers = 2458MB work_mem = 1MB fsync = on wal_sync_method = fdatasync full_page_writes = on checkpoint_segments = 300 checkpoint_timeout = 15min checkpoint_completion_target = 0.7 segsize=1GB(default) [patched postgresql.conf (add)] checkpointer_fsync_delay_ratio = 1 checkpointer_fsync_delay_threshold = 1000ms [DBT-2 driver settings] SESSION:250 WH:340 TPW:10 PRETEST_DURATION: 1800 TEST_DURATION: 1800 * Test Server Server: HP Proliant DL360 G7 CPU: Xeon E5640 2.66GHz (1P/4C) Memory: 18GB(PC3-10600R-9) Disk: 146GB(15k)*4 RAID1+0 RAID controller: P410i/256MB (Add) Set off energy efficient function in BIOS and OS. Best regards, -- Mitsumasa KONDO NTT Open Sorce Software Center
Вложения
В списке pgsql-hackers по дате отправления: