Thread: memory usage
I have a Borland C++ program (running on NT server) which connects to PostgresSQL (V6.5) via ODBC (V6.5). The program reads data file and updates database at regular intervals. The program has close all connections when execution finishes. This program seems to use a lot of the memory on the linux server, and the memory doesn't seem to be released at the end of execution. The same thing occurs when I try to connect to the database from MS Access via ODBC. Could the problem comes from front-end program, the ODBC, the database or any other source? Any idea? The current solution is to reboot the linux server every now and then to fix this problem. Of course this is a short term solution and I'm looking for a permanent solution. Thanks.
Ms. Wong, > This program seems to use a lot of the memory on the > linux server, and > the memory doesn't seem to be released at the end of > execution. The same > thing occurs when I try to connect to the database from > MS Access via > ODBC. It's been my experience that Win32 ODBC does not drop connections until the database client is closed (e.g. MS Access is shut down). For example, I have a program that connects MS Access through ODBC to a remote MySQL database via an SSH tunnel; the tunnel does not close until I shut down MS Access even if I kill the parent shell. ODBC keeps it alive. If, howoever, the connections (and their memory usage) are persisting after termination of the client application, I would look to your network environment for answers. It could be that you are routing through a switch that is, for some reason, keeping the client-server connection open after data has stopped transmitting. The last place I'd look would be the linux server; my experience is that Linux is worlds better at managing connections than Win32 or cheap Ethernet switches. Good Luck! -Josh
Carolyn Wong writes: > This program seems to use a lot of the memory on the linux server, and > the memory doesn't seem to be released at the end of execution. Are you quite certain that this is actually what is happening? Linux memory usage can be confusing. -- John Hasler john@dhh.gt.org (John Hasler) Dancing Horse Hill Elmwood, WI
John Hasler wrote: > > Carolyn Wong writes: > > This program seems to use a lot of the memory on the linux server, and > > the memory doesn't seem to be released at the end of execution. > > Are you quite certain that this is actually what is happening? Linux > memory usage can be confusing. I run 'top' to see cpu usage when running the program. The 'postmaster' command seems to stay after my program terminates. Because the program runs every 10 minutes, when it restarts, the mem usage for the same command increases. > -- > John Hasler > john@dhh.gt.org (John Hasler) > Dancing Horse Hill > Elmwood, WI
Hi all, Hi all, Before all, a little (off-topic) comment: >It's been my experience that Win32 ODBC does not drop >connections until the database client is closed (e.g. MS >Access is shut down). "There is some things that only Micro$oft can do for you..." Ok. Let's work. I posted a mail before explaining a strange cituation if my Postgresql: when I use date_part() function to split day, month and year of a date type column, it returns one day before. In other words, '2000-01-01' returns day: 31, month:12, year: 1999. I'm using OS/2 with Fix Pack 12, Postgresql 7.0.2. Can any one explain this? []'s Edipo Elder F. de Melo
Elipo,
> Ok. Let's work. I posted a mail before explaining a strange
> cituation if my Postgresql: when I use date_part() function to split
> day, month and year of a date type column, it returns one day before.
> In other words, '2000-01-01' returns day: 31, month:12, year: 1999.
No, I was hoping an expert would take this on. Lemme test it on Linux:
create table test_date AS (haveadate DATE );
insert into test_date ( haveadate )values ( '2000-04-30' );
select haveadate, date_part('month',haveadate),
date_part('day',haveadate),date_part('year',haveadate) from test_date
haveadate
2000-04-30 4 30 2000
No problem here. Or on PG-ACCESS.
The problem must be in the OS/2 compile, probably some problem in
accessing the internal clock?
-Josh
--
______AGLIO DATABASE SOLUTIONS___________________________ Josh Berkus Complete
informationtechnology josh@agliodbs.com and data management solutions (415) 436-9166 for law firms, small
businesses fax 436-0137 and non-profit organizations. pager 338-4078 San
Francisco
>> Ok. Let's work. I posted a mail before explaining a strange
>> cituation if my Postgresql: when I use date_part() function to split
>> day, month and year of a date type column, it returns one day before.
>> In other words, '2000-01-01' returns day: 31, month:12, year: 1999.
> No problem here. Or on PG-ACCESS.
There's a known (and fixed for 7.1) bug of this sort that occurs on
spring daylight-savings-time transition days: the date-to-timestamp
conversion function picks the wrong timezone offset to interpret
"midnight" in, yielding a timestamp for 11PM of the prior date.
On the fall DST date, you get a timestamp for 1AM. For example,
in USA zones:
play=> select '2000-04-02'::date::timestamp; ?column?
------------------------2000-04-01 23:00:00-05
(1 row)
play=> select '2000-10-29'::date::timestamp; ?column?
------------------------2000-10-29 01:00:00-04
(1 row)
Not sure how this would apply to 2000-01-01, though. What timezone
are you in, anyway?
regards, tom lane