From: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
To: Simon Hardingham <simon@netxtra.net>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] ODBC / Access causes "Stuck on TLB IPI wait (CPU#1)"
Date: Tue, 15 Feb 2000 11:55:56 -0600
Message-ID: <20000215115556.B4490@rice.edu> (raw)
In-Reply-To: <4DCB16536FCBD311897000A0C92A02EDB5D2@sauron.netxtra.net>
References: <4DCB16536FCBD311897000A0C92A02EDB5D2@sauron.netxtra.net>
On Tue, Feb 15, 2000 at 09:17:03AM -0000, Simon Hardingham wrote:
> Hi,
>
> Have a reasonable sized postgres database with a number of tables. I have
> set up an Access 97 database with ODBC links to these table and queries so
> they can manage the database. However, increasingly when opening these
> linked tables we are getting server crashes (and Access hangs) with
>
> Stuck on TLB IPI wait (CPU#1)
This is a kernel error message. FYI, the TLB is the Translation Look-aside
Buffer, part of the very low level virtual memory and cache implementation
inside the Intel CPU, and IPI is Inter-Processor Interupt. Based on
a quick search of the linux-kernel mailing list archives, it's a bug
triggered by lots of memory and network use, and I can't seem to find
if it was finally stomped out, for sure. There are lots of SMP fixes in
the development kernel (2.3.X) Much of the SMP work has been completely
redesigned.
>
> The database works fine with all the JDBC manipulation and psql, never had a
> crash from these. Can anyone suggest a solution as the alternative is
> create some sort of web front-end to do all the manipulation, slow, complex
> etc. etc.
Access is notorious for creating ugly, huge SQL queries, which then take
a lot of memory to process. There's some switch in the ODBC driver to
catch on particular case and optimize it, I believe. This would only
mask the real problem, of course.
>
> System is:
> Dual PIII 450, 128MB Ram,
> RedHat 6.0 (no kernel upgrades etc)
Ah, I bet here's the culprit. RedHat 6.0 shipped with a fairly early 2.2.X
kernel, and there's been a number of SMP bug fixes, as I mentioned above.
I'm running kernel 2.2.10 on a dual PII 400 and haven't seen this bug,
and I have ran some nasty large querys that consume all available memory
(or, I should say, one of my co-developers has ;-) Heck, I should upgrade:
2.2.14 is out, and 2.2.15 is about to be released. And looking at the
release notes, 2.2.13 says "A TLB handling race on SMP boxes has been
fixed.", that's probably the vary bug. Yikes I better upgrade!
Hmm, it just occured to me, you said 'server crashes' above. At first,
I took that to mean the postgresql server program died. If you meant
the entire server machine is crashing, as is likely to be the case,
based on your error message and what I've seen in the linux-kernel list,
realize that's a kernel issue. One cardinal rule of Unix is that userspace
programs _should not_ be able to crash the system. If they can. that's
a bug that needs to be fixed, in the kernel, not worked around in the
application. You're much more likely to get the right answer in a linux
forum, rather than here. Although, in this case, I guess you licked
out ;-)
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: reedstrm@wallace.ece.rice.edu, simon@netxtra.net
Subject: Re: [INTERFACES] ODBC / Access causes "Stuck on TLB IPI wait (CPU#1)"
In-Reply-To: <20000215115556.B4490@rice.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox