Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 3 of 3 total |
Specific situation |
Fri, Jan 4 2019 8:41 AM | Permanent Link |
Jose Eduardo Helminsky HPro Informatica | We have recently migrated our biggest application from DBISAM to ElevateDB.
Scenario: Around 200 users running on Windows 12 and all access are throught C/S. There are no AV in the server. After some hours of using we realize some information we need to check: Before (DBISAM) Memory consumption: 500Mb CPU usage around: 5% After (ElevateDB) Memory consumption: 5Gb CUP usage around: 15% The above values are regular or there are some issues here ? But the main trouble we are having is some freezes in some situations. After debug the source code, I realize the reason of these freezes (at least from my point of view). When I use following statement to check if a table exists or not "if Database.Execute('select * from information.tables where name=' + QuotedStr(TableName)) > 0 then begin" It takes two seconds to give me the result. The question is: Is this normal ? There are some setting we can change to decrease this time or anything else we can do ? Eduardo |
Fri, Jan 4 2019 9:31 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Jose
There was a topic recently about memory consumption and it looks like 60 - 70 MB (or it maybe Mb I can never remember) per user so for 200 users 5GB looks light Subject: Estimating memory needed for server Date: Tue, 20 Nov 2018 13:53:51 -0500 Lines: 13 Message-ID: <EF0DEAC7-D04E-4A17-BA61-7B58507D9BDF@news.elevatesoft.com> Newsgroups: elevatesoft.public.elevatedb.general Path: www.elevatesoft.com CPU usage will depend on what you're doing so no idea if 15% is good, bad or normal. 2 seconds to read from one of the system tables seems a lot. There will be a small overhead because database.execute is creating a query on the fly, but that would be ms at worst. If you're doing this a lot it could be that you're just hammering the system table with read locks and its taking a while for your's to reach the top of the heap. I remember a post not so long back where the poster had a very large amount of tables (or it might have been databases) defined and that was slow. Can't remember what Tim said about it. It might well be the case that you don't need to check for a table's existence. If you try and open it and its not there then as long as its defined in the catalog ElevateDB will create it for you. The only time you should need to check if it exists is if you're creating or dropping it. Roy Lambert |
Fri, Jan 4 2019 11:26 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Eduardo,
<< The above values are regular or there are some issues here ? >> There is absolutely no way to answer that without seeing your entire application and how its structured, along with the database, and doing some test runs to see what is using the memory. If you want to know what sessions are consuming memory, and how much, you can query this system information table: https://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=ServerSessionStatistics_Table << When I use following statement to check if a table exists or not "if Database.Execute('select * from information.tables where name=' + QuotedStr(TableName)) > 0 then begin" It takes two seconds to give me the result. The question is: Is this normal ? >> No, that is not normal. It illustrates that there's an issue, but I'm not sure where it would be without running your application here and seeing what is taking so long. Any queries on that system information table will result in a catalog *read*, which can occur among thousands of users without any delays. The only thing that will cause such a query to take too long is if something else is constantly updating the catalog (CREATE/ALTER/DROP/RENAME), thus blocking reads for short periods of time. Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Monday, May 6, 2024 at 12:23 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |