Apache OpenOffice (AOO) Bugzilla – Issue 98548
[MSSQL]Memory leak when opening tables via ODBC
Last modified: 2013-01-29 21:47:02 UTC
When opening a table or caling a table via a subform and datagrid the used memory on the machine is growning depending on the size of a table (several MB 's)OO gives this memory back after closing OO. Native , FlatText and Spreadsheets datbases do not have this behaviour. ODBC JDBC and alse MySQL connector suffers from this memory leak. Found it in 2.41 and 3.0 Very easy to verify open and close some tables and check the memory on the machine
putting into pool, correcting priority
Frank, "Performance" is maby not the right keyword, its a real ShowStopper, opening several tables is "eating up " all the memory specialy when there are subforms involved, then you easyly losse 100's MB in notime !
we don't have a better keyword for that ... However, I really think that unreasonable memory consumption also fits into the "performance" category - this is not only about speed, but in general about how well OOo uses system resources (both time and memory), at least in my understanding. The reason why I added this keyword is that performance is a major goal for OOo 3.1+, and I want to ensure that we deal with this issue here in this course.
Frank, Thanks for your interest in this problem. I fuly understand the performance idea, I call it "ShowStopper" because we are testing OO as frontend to a SQL sever and we have complains from our users who there machines runned out of memory and stoped most off there aplications with sometimes lost of data etc.... We try to make OO the main aplication for all our users,unfortunely, this days most off the data is stored on several SQL servers, if You think using OO for this tasks (now and in the future) is not a good Idea, please let me known before we start more projects. We are a Belgian Publisher, we uses OO to produce over 6000 full Color Print Pages and we mentain the "freeContent" of hunderd's Webpages with OO In the near future we planed to use OO also to store structured Web on the Webservers aan then retrieving this content via OO for Printed Pages. Thanks Fernand Thanks Fernand
hmm, cannot reproduce with a 20K table (1 PK column and 10 VARCHAR columns, all columns filled with random 20-character text in all rows) on a MySQL server, connected via JDBC, in OOo 3.0. Opening the big table the first time gives 15 MB or so which are used up, but this then doesn't change anymore - subsequently opening/closing the table lets the memory consumption go up and down a little, by a few MB, but everything is given back, as far as I can see. Could you please try to give a concrete example - a SQL script to generate the table in question, the version of the DB/driver you use?
Hi Frank, hmm.. I loaded the latest MySQL connector and made a ODBC connection and indeed, no leaks not in 2.4 not in 3.0. I still find (also for 3.0) the same leaks with the standard Windows ODBC driver connected to MSQL 2000. We planned to move to MySQL anyhow, but or Web provider sticks to MSQL, I will aks them for a "open" connection to some harmeless tables, then i make a ODB file and drop this here. Thanks Fernand
Frank, I found that the acces to or MSQL Webserver is to complex passwords..tct.. But anyhow I did some more testing. I think it comes all to the choiche of the driver and the SQL server. ODBC and MSQL = leaking ADO and MSQL = no leaking but troubles with some SQL statements and paramatered Querys ODBC and MYSQL = no leaking OO-Native-Connector to MuSQL = minimal leaking Hope it helps Fernand
Last week I issued 102625 (Table Data View + ODBC issues select * from table to get only key data). By the looks of it, this is the same issue. OOO retrieves unnecessarily the full table to get only the key values. The impact on the machines memory depends on the table structure (f.e.large blobs in the table) and indeed on the odbc driver and database client used. This is not an OOO memory leak however. Memory is released when the resultset is closed, unless the ODBC driver or database client leak memory...
changing summary Should be better with version 3.1 and also the upcomming version 3.2 in winter
id indeed far more better sinds 3.2 ! = resolved !
Drew >> is realy RESOLVED
Looks like this one is fixed or works now in a newer 3.3 version.
I'm closing this one. If we have still memory leaks in the newest version, feel free to reopen it.
oj, tested on 3.3 rc6 32.000 records table and loses still 3-4 MB par opening Good news, 3.3 is 10% faster when loading all records in Beamer (25 secs vs 30 secs)