Thanks for the suggestions that I received. We finally managed to find and correct the issue so I thought I'd share it with the group to close this thread.
Essentially, if we try to use a local catalog entry for the DB2 10.5 database we consistently get slow response times (4s for 32-bit version and 6s for 64-bit!). But by creating a separate catalog entry to go through the network back to original database on DB2 V10.5, it works super fast! So, as odd as it seems, the work around is really not to try to connect to DB2 10.5 via a local catalog entry... Just thought I'd share that with everybody in case anybody else is experiencing these performance-related issues with DB2 10.5. On Mon, Apr 14, 2014 at 10:27 PM, Greg Sabino Mullane <g...@turnstep.com>wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > > We're finding that simply creating a connection maxes out one of the > CPU's > > and consistently takes over 4s (but sometimes it manages to create the > > connection in about .2s). > ... > > If any body can offer up any sort of suggestion, I'd be most grateful - > > we're truly stumped. > > Nothing jumps out right away. You should probably dig deep and see where > the pause is, by running it under strace. > > - -- > Greg Sabino Mullane g...@turnstep.com > End Point Corporation http://www.endpoint.com/ > PGP Key: 0x14964AC8 201404141925 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > -----BEGIN PGP SIGNATURE----- > > iEYEAREDAAYFAlNMmPoACgkQvJuQZxSWSsjxFACgv+LgzhH1On5LGQ44Pebns8Li > cBkAoIxt8rPaBMrvnJIVwI4Pg/d1rQzf > =uwKW > -----END PGP SIGNATURE----- > > >
