Thursday, March 22, 2012

System.OutOfMemoryException error

Hi,

I migrated our company's ASP.Net web appplication from a regular Pentium 4
machine to a multiple xeon processors machine. The web application was
acceptable in speed on the old machine, I was expecting to get a better
performance in speed when I did the migration. But neither users or I felt
the difference since the migration.

This is fine. But now I have been getting System.OutOfMemoryException errors
from different ASP.Net pages every now and then on the new machine, same
problems never happened to the old machine. Both machines are running
Windows 2000 sever with SP4.

Any Ideas why System.OutOfMemoryException errors happen to faster machines?

TIAyou probably have thread race conditions that never happened on a single
processor system. check for correct locking on all static variables (vb
modules).

-- bruce (sqlwork.com)

"Ed Chiu" <EdChiu@.discussions.microsoft.com> wrote in message
news:F2D84B2D-4CC6-4DC5-AB4D-D51B16CA5488@.microsoft.com...
> Hi,
> I migrated our company's ASP.Net web appplication from a regular Pentium 4
> machine to a multiple xeon processors machine. The web application was
> acceptable in speed on the old machine, I was expecting to get a better
> performance in speed when I did the migration. But neither users or I felt
> the difference since the migration.
> This is fine. But now I have been getting System.OutOfMemoryException
> errors
> from different ASP.Net pages every now and then on the new machine, same
> problems never happened to the old machine. Both machines are running
> Windows 2000 sever with SP4.
> Any Ideas why System.OutOfMemoryException errors happen to faster
> machines?
> TIA
Thank you for the reponse. But I don't understand you response.

For starter, what is "thread race conditions"? Secondly, why do I need to
lock static variables?

I only have one instance of aspnet_wp .exe running, I do not create web farm
or web garden environment.

Thanks Again

"Bruce Barker" wrote:

> you probably have thread race conditions that never happened on a single
> processor system. check for correct locking on all static variables (vb
> modules).
> -- bruce (sqlwork.com)
>
> "Ed Chiu" <EdChiu@.discussions.microsoft.com> wrote in message
> news:F2D84B2D-4CC6-4DC5-AB4D-D51B16CA5488@.microsoft.com...
> > Hi,
> > I migrated our company's ASP.Net web appplication from a regular Pentium 4
> > machine to a multiple xeon processors machine. The web application was
> > acceptable in speed on the old machine, I was expecting to get a better
> > performance in speed when I did the migration. But neither users or I felt
> > the difference since the migration.
> > This is fine. But now I have been getting System.OutOfMemoryException
> > errors
> > from different ASP.Net pages every now and then on the new machine, same
> > problems never happened to the old machine. Both machines are running
> > Windows 2000 sever with SP4.
> > Any Ideas why System.OutOfMemoryException errors happen to faster
> > machines?
> > TIA
>
> you probably have thread race conditions that never happened on a single
> processor system. check for correct locking on all static variables (vb
> modules).
> -- bruce (sqlwork.com)

I agree.

If both of the following conditions are true:
1. Your database is in an SQL Server or MSDE
2. That SQL Server lives on the same box as your web server
Then:

Beware of "Parallelism". SQL Server, on a multiprocessor box may "break up"
activities of your SQL so that portions of an activity runs in parallel
through multiple CPU's and then SQL Server gathers up the results from each
thread and then serializes them back together. Occasionally, depending on
the nature of the SQL syntax, these "Parallelized threads" can deadlock each
other.

I have only seen this occasionally, but if you want to try it out, dig
through your code to locate any SQL that might be executing when your
application displays this behavior. You can then run SQL Server Query
Analyzer, Set the "Show Execution Plan" option, paste your SQL code, run it,
and then look at the "Execution Plan" tab. If you see any icons that
mention parallelism, then you might consider adding the OPTION (MAXDOP 1)
query hint to your SQL:

SELECT foo
FROM Bar
WHERE fee = fum
OPTION (MAXDOP 1)

"MAXDOP" means "MAXimum Degree Of Parallelism", basically telling SQL Server
to not split the operation over more than one CPU.

If you think that this Parallelism thing is your problem, you can do a "Full
Text Search" on "MAXDOP" in SQL Server Books Online. I cannot imagine why
it doesn't have an index entry.

You could also ask about it over in the
microsoft.public.sqlserver.programming newsgroup.
--
Peace & happy computing,

Mike Labosh, MCSD

"Mr. McKittrick, after very careful consideration, I have
come to the conclusion that this new system SUCKS."
-- General Barringer, "War Games"
I am sorry, the SQL server runs in another server, not with thw web sever.
Please remember we never experienced the same problems with the old web
server.

"Mike Labosh" wrote:

> > you probably have thread race conditions that never happened on a single
> > processor system. check for correct locking on all static variables (vb
> > modules).
> > -- bruce (sqlwork.com)
> I agree.
> If both of the following conditions are true:
> 1. Your database is in an SQL Server or MSDE
> 2. That SQL Server lives on the same box as your web server
> Then:
> Beware of "Parallelism". SQL Server, on a multiprocessor box may "break up"
> activities of your SQL so that portions of an activity runs in parallel
> through multiple CPU's and then SQL Server gathers up the results from each
> thread and then serializes them back together. Occasionally, depending on
> the nature of the SQL syntax, these "Parallelized threads" can deadlock each
> other.
> I have only seen this occasionally, but if you want to try it out, dig
> through your code to locate any SQL that might be executing when your
> application displays this behavior. You can then run SQL Server Query
> Analyzer, Set the "Show Execution Plan" option, paste your SQL code, run it,
> and then look at the "Execution Plan" tab. If you see any icons that
> mention parallelism, then you might consider adding the OPTION (MAXDOP 1)
> query hint to your SQL:
> SELECT foo
> FROM Bar
> WHERE fee = fum
> OPTION (MAXDOP 1)
> "MAXDOP" means "MAXimum Degree Of Parallelism", basically telling SQL Server
> to not split the operation over more than one CPU.
> If you think that this Parallelism thing is your problem, you can do a "Full
> Text Search" on "MAXDOP" in SQL Server Books Online. I cannot imagine why
> it doesn't have an index entry.
> You could also ask about it over in the
> microsoft.public.sqlserver.programming newsgroup.
> --
> Peace & happy computing,
> Mike Labosh, MCSD
> "Mr. McKittrick, after very careful consideration, I have
> come to the conclusion that this new system SUCKS."
> -- General Barringer, "War Games"
>

0 comments:

Post a Comment