Don & Chris, > For each radar XXXX: > > request EXP ".XXXX" IP > > The products don't exist...yet. When RPG Build 12 is fielded late Aug to > late Sept, the EXP product will exist. I think that's the cause of the slow response. On the newly-promoted aggregation system, each downstream LDM process will search though the product-queue for the most-recently received matching data-product. The LDM queue is implemented as a unidirectional skip-list (from oldest data-product to most-recent) so searching for the most-recently received data-product is an O(log N) operation. On average, each NEXRAD2-requesting downstream LDM will find a matching product after 77 such searches. Because there are no EXP data-products in the queue, however, each EXP-requesting downstream LDM will search the entire queue before giving up, which is an O(N log N) operation. I think you have 154 processes searching the entire product-queue for products that don't exist and that this is eating-up the CPU-s and delaying the response. I tested that hypothesis here and the restart time went from 30 seconds at the most to about three minutes. The LDM wasn't relaying any data, so that might account for its response being less than 10 minutes. I suggest that you remove the requests for EXP data until such data-products become available. > Chris > -- > > Chris Calvert > Software Engineer > National Weather Service > WSR-88D Radar Operations Center > 1313 Halley Circle, Norman, OK 73069 > (405) 573-3323 Regards, Steve Emmerson Ticket Details =================== Ticket ID: QKY-452311 Department: Level II Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.