Disk volume is down(2074). Dedupe DB and dedupe data sharing same file system
Ramdonly my redhat media server 18.104.22.168 goes down with "Disk volume is down(2074)" error message. It happens on Fridays (but not alls). Usually it get fixed getting up the pool using /usr/openv/netbackup/bin/admincmd/nbdevconfig -changestate -stype PureDisk -dp dbPoolBO -dv PureDiskVolume -state UP or rebooting the server.
I have read that this problem is related with I/O disk and some timeouts. It make sense to me as that this problem only happens on Fridays when full backups runs. In order to deal with the IO I have reduced the maximum of the concurrent jobs too.
Deduplication database is located in the same file system as the deduplication Data. So, maybe this can be one of the cause. Using the iotop tool I have seen that Postgres jobs are reading/writing intensively in the same file system.
I wonder if postgres database can be moved to another file system to reduce IO in the deduplication Data file system. Is it safe? Is it worth it?
Another problem indicator I have seen is the /deduplication/databases/pddb/postgresql.log logfile. There are many lines stating a parameter to be tuned
<2013-03-13 05:31:55 CET>LOG: checkpoints are occurring too frequently (16 seconds apart)
<2013-03-13 05:31:55 CET>HINT: Consider increasing the configuration parameter "checkpoint_segments".
So maybe postgress database is not behaving as expected. It is safe to tune this parameter?
These are only some thoughts and maybe I am pointing in the wrong direction. Please feel free to ask more logs,etc
Thank for your time