IDS Forum

Performance problem during log backup

Posted By: Marcus Haarmann
Date: Wednesday, 27 August 2014, at 4:41 p.m.

Hi experts,

we were forced to create a new instance for our document storage (originally set up as table with blob column,
using a smart blob storage). The new instance is using byte columns (yes I know we cannot use HDR ...).

The old instance was stuck because of an undefined error on inserting new data and nobody was able to solve
the situation.
The error was related to the meta data, looking at the af file.
Now, we converted everything to byte content, cause we do not really need a smartblob functionality
(other than HDR, we are using mirroring now to cope with hardware errors). Took a while
to copy the data from blob to byte.
When the instance was copied, we had logging turned off, to copy the data with higher throughput.
The data was copied with a JAVA program, which inserted the records with 10 parallel threads on the
target machine (since no internal cast from blob to byte is available).
Now, the machine has taken over the load and we have switched on logging.

The new situation is that whenever a logfile gets full (like every 15 minutes), the backup (ontape) starts
writing the header of the logfile and then stops. About 20 minutes later the logfile will be written.
Then the next logfile is already full and backup starts again.
Normally, on our other instances, writing logfiles is a process running for some seconds, not several minutes.
Inserting new data in this state is veeery slow, can take minutes for one row.

We have now turned off log files for the moment, and added a separate instance to collect the traffic
because the instance is basically unusable in this state.

Also, the smaller instance with comparable setup (same table, also byte col for document content),
tends to have the same behaviour (though we can write a logfile there in about 3-4 minutes at the moment).

The hardware is not very fast, cause normally the documents (mostly compressed pdf) should be written once,
never changed and are retrieved again by primary key on demand (number of written documents 100 compared to 10
read documents).
Initially we had the instance running with smart blobs, and memory usage
was 500mb. Storage size with smart blobs was around 2.5TB.
We ran into several problems:
- Backup Level 1 blocked instance for 1.5h at night (fixed bug in FC8W...).
- finally SQL Error on insert of new rows, an unclear situation which IBM was not able to reproduce by now.
We changed the application to be able to address two instances.
Since there was no hint from IBM how to setup the database to not run into the situation again,
we decided to use "old" byte columns instead of blob columns.

The setup now is as follows:
IDS 11.70FC7GE on Linux, Double processor Opteron, FC 8GBit to SAN, Raw Devices on lvm partitions
Three tables in the database, biggest one around 200mio rows. In total around 350mio records.
Chunk layout: 1x rootdbs 100GB (for table), 6x blobdbs 500GB (for bytes).
Allocated memory 5.5GB (SHM 256mb, add 64mb, buffers 80000x2k)

What we found out so far:
Written logfiles are significantly bigger than logsize (probably because the byte content is not in the logs
and is read separately).
While logfiles are backed up, we encounter a extreme read activity on the blob chunks (onstat -g iof).
Ok, this is not a very common setup for a relational database, we are currently evaluating other databases
which might do a better job on this amount of documents.
I do not like that personally, since our administration is used to do basically everything with Informix.
But the question is:
What is generally wrong with the setup ?
Why is logfile writing taking that long ?
Why does the big instance block without any error message when inserting new rows ?
What can we tune to make it work ?

Maybe somebody can give us a hint. The intended setup for us would be a HDR instance pair,
using Smart Blobs, Level 0 Backup on sundays, Level 1 backup + Logbackup during the week.
Since there are only a couple of tables involved, maybe an ER setup with bytes could be a solution,
but we are sort of desperate because each try to store such an amount of documents in an Informix
instance was not very successful so far.

Thanks in advance for your input.

Marcus Haarmann

Messages In This Thread

• Performance problem during log backup
  Marcus Haarmann -- Wednesday, 27 August 2014, at 4:41 p.m.
  • Re: Performance problem during log backup
    Art Kagel -- Wednesday, 27 August 2014, at 5:10 p.m.
    • Re: Performance problem during log backup
      Marcus Haarmann -- Thursday, 28 August 2014, at 7:46 a.m.
      • Re: Performance problem during log backup
        Art Kagel -- Thursday, 28 August 2014, at 8:08 a.m.
        • Re: Performance problem during log backup
          Fernando Nunes -- Thursday, 28 August 2014, at 8:19 a.m.
          • Re: Performance problem during log backup
            Marcus Haarmann -- Thursday, 28 August 2014, at 8:43 a.m.
            • Re: Performance problem during log backup
              Art Kagel -- Thursday, 28 August 2014, at 9:03 a.m.
              • Re: Performance problem during log backup
                Fernando Nunes -- Thursday, 28 August 2014, at 10:12 a.m.
                • Re: Performance problem during log backup
                  Fernando Nunes -- Thursday, 28 August 2014, at 10:01 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.