EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Expected database load times
From: Andrew Johnson <[email protected]>
To: <[email protected]>
Date: Fri, 15 May 2015 12:34:08 -0500
Hi Klemen,

On 05/15/2015 12:11 PM, Klemen Vodopivec wrote:
> I'm interested in the time it takes to load database(s) with
> thousands of records. For about 100,000 records we're seeing IOC boot
> times in range 30s or more when loaded with dbLoadRecords(). Without
> related database the IOC boots instantly. Most records connect to
> asyn port. Disabling macro substitution doesn't seem to have much
> effect. When spread into several files with about the same amount of
> records one can observe gradually slowing down the time it takes to
> load one file.

You're loading 100,000 records into a single IOC? Our largest IOC here
has only about 33,000 records, although there's no fixed limit.

It might help to have your startup script call dbPvdTableSize(65536)
before you load your DBD file(s). This makes the hash table that stores
the record instances as large as possible, which should speed up name
searches and may help with your load times.

The iocsh command "dbPvdDump pdbbase" prints a report on the current
state of that hash table; I would not suggest giving it the third
verbose argument if your IOC has 100,000 records in it as it then prints
out all the record names.

> What are others' experiencing? Is there anything to speed it up?

I can't think of anything else which might cause such a slow-down. Let
us know if the above suggestion helps.

- Andrew

-- 
Light thinks it travels faster than anything but it is wrong.
No matter how fast light travels, it finds the darkness has
always got there first, and is waiting for it.
    -- Terry Pratchett, Reaper Man

References:
Expected database load times Klemen Vodopivec

Navigate by Date:
Prev: Expected database load times Klemen Vodopivec
Next: Re: "epicsMutex pthread_mutex_unlock failed" with pyepics/pcaspy Jameson Graef Rollins
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Expected database load times Klemen Vodopivec
Next: RE: Expected database load times Dalesio, Leo
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·