Additional Information

Details of specific case....

Performance issues have been resolved. As suspected, there were several issues going on at the same time.

1. In regard to disk latency. The disk storage vendor pointed out that there were several servers competing for cache. So, in order to eliminate this variable, we turned caching off on the volumes where the Oracle database resides. At this point, the storage was showing peak cache use 138%. The system administrator went through all the other servers and turned off caching on the servers that didn't need it. He also freed up lots of storage no longer needed.

2. The indexes of the Oracle tables showing long response time (z30, z36h, z01, and z02) were rebuilt. (The slow response was shown by "select count(*) from znn;" taking more than one minute.) See Article 000024902 (SQL "select count" is slow).

3. The pc_server logs showed excessive activity for C990n (z39.50) programs from http:cylinders.library.xxx.edu, a local application accessing the server via z39.50. Web programmers implemented a "memcached" server between the Cylinders server and the Aleph server. That reduced the Z39.50 traffic to half.

In total, performance has improved considerably. It had nothing to do with the service pack!

I loaded the 3rd quarter LTI AUP service:
- 18,230 authority records loaded in 13 mins and 41 secs and indexed in 2 hrs 7 mins and 12 secs.
- After authority indexing was completed I released ue_11. It dumped about 173,000 bibs in the queue to be re-indexed. This took 1 day, 19 hrs, 53 mins and 10 secs.
- Then I loaded the 78,110 bibliographic records corrected by LTI which loaded in 55 mins and 04 secs and indexed in 11 hrs, 36 mins and 39 secs.

<end specific case details>

See also, the following Articles:

* Procedure for diagnosing slow Aleph system performance
* Aleph is slow ***MASTER RECORD***
* System/search slowness **MASTER RECORD**

* PC connection to server extremely slow 

• Article last edited: 10/29/2014