FWWG

Thursday 6 Jul 2006, 14:00 → 16:00 Europe/Zurich

104/R-A10

Slides 2006-07-06_FWWG_PVSSOracleArchiver.pdf 2006-07-06_FWWG_PVSSOracleArchiver.ppt

Participants: Jim, Fernando, Peter, Maria, Valdimir, Svetozar, Manuel, Frank, Clara, Stefan, Hervé, Wayne 6th July 2006 Manuel gave an overview of the status of the PVSS Oracle testing, including a summary of the tests performed, together with a description of the conditions under which they were performed, a list of the known problems and the tests still to be performed. The details can be found in Manuel's slides which are attached. However, as a very brief summary: - Good throughput can now be achieved from individual clients both on Windows (> 2000 changes per second) and Linux (>3000 changes per second) - Very high insertion integrated rates can be achieved with large numbers of clients (up to 170 tested). There is almost linear scaling with the number of RAC nodes. However, there is a known problem when the database tries to create new table spaces with high data rates. This is believed to be an Oracle bug and is being followed up with the company. However, for the more moderate rates currently foreseen there should not be an issue. - Problems were seen with the data queries and these have been optimised but not yet tested as this requires ETM to modify the RDB manager code. - The performance with alarms is felt to be low, but probably acceptable for a realistic scenario. However, this is being followed up with ETM to investigate possible means of improving this performance. Other issues discussed during the long meeting: - Would it be possible to run multiple RDB managers in a single PVSS system? According to the documentation this would be possible. However, it has not been tried and it is not obvious what the advantage of this would be. - Is it possible to run the RDB manager and file archives in parallel in a single PVSS system? NO. - The assumptions made for the target querying performance seem low. The experiments were requested to provide a more realistic target performance. ALICE has submitted a document to IT-CO for review which also includes requirements for retrieval. - Issues with the start-up time. The start-up time has been significantly reduced. However, it is not clear that the query to find the time of the last value inserted in order to determine whether the values in the lastValArchive should be inserted is meaningful - in any case the current implementation is incorrect. ETM will be asked to remove this functionality - or at least have a config option to suppress it. - The dpGetPeriod function can be called with a argument which specifies how many additional values should be retrieved either side of the specified time period. This is a very time consuming query. For trending one can specify a default which is then used by all trend widgets. It was suggested to set this to 0 by default with the trending tool. However, when calling this function directly from a script one can specify other values. - The question of whether it should be possible to request archive data from a system which is currently not running was required or not. Seems to be a nice to have but not mandatory. - It was once again stressed that PVSS uses the internal ID for providing the pointer to the data in the dB. Hence, if a system were to be regenerated it would be essential to ensure that the IDs were identical to the original system. It was recommended to perform an ASCII export and archive the resulting file. ETM will be requested to allow the use of the ID as a parameter when creating dps. (This functionality is not in the standard control language but is available in the C++ API and used by the ASCII manager). - W.r.t. the alarm performance issue noted above, it was suggested to perform an alarm avalanche to see if this system recovers correctly. This can be done relatively quickly. - If one system wishes to retrieve data from a long-time in the past off-line tables would need to be put on-line and the view which would be queried would need to be modified to include these additional table spaces. This will slow down the querying for all clients. - There was then a long discussion as to how to set-up a distributed system w.r.t. the database. The following options exist each with pros and cons: * Single database schema and account and all systems writing to this. Current tested set-up. Although there is effectively one history table and each PVSS systems has its own partition within this table. This allows any PVSS system to query the data from any other system directly from the database. However, the data of a system producing a low data rate compared to another system will be split over many table spaces. Hence, to retrieve this data will require to have many table spaces on-line. However, the time period that is 'on-line' would be the same for all systems. To be checked with the dB people whether it is possible to have partitions with different sizes. * Use PVSS Archive Groups. One could imagine having an archive group per sub-detector or even per PVSS systems. Each group would have its own table space and hence the rate at which a table space filled up would not be influenced by other systems not connected to this group. However, systems could still access directly the data archived in other groups. * ATLAS proposes to have a separate account for each sub-detector. This would solve the problems of couple between sub-detectors but would mean that to retrieve data from a sub-detector from the central DCS system would require to go via the system having produced the data. This means loading further the systems which are already the most loaded. - Frank asked whether the schema the data is stored in could be passed with the query. If this were to be possible, it would solve the problem mentioned above for ATLAS. This is not thought to be straightforward. There was no conclusion to this lengthy discussion. It was agreed that a discussion with the IT dB specialists should be arranged to discuss the pros and cons of the various options. This will be set-up for when Manuel is back from holiday. In the meantime the experiments should discuss internally their needs. It was agreed to postpone Jim's presentation on the ATLAS PVSS-COOL implementation until Monday 10th July at 14:00 in 14/4-002.