SQL Server Page Life Expectancy drops from 1500 to 144, then we get deadlocks on various tables

Our customers are running year end activity and the memory is thrashing.  Rarely used data (or data the Buffer Manager does not predict) is being called into RAM.  

After PLE drops to 144 or 86 sometimes, it slowly rises, it can get up to 800 or 900 before in drops again to the lows.   I have already removed many indexes that were bad.  They were bad because they were speeding up 12k queries, but slowing down 2.7 million queries (see real production numbers below).

Total Writes      Total Reads      Difference
2,754,287      12,404      2,741,883

My production server has 8.3 Gig of RAM and SQL Server is set to 7.5 Gig.  I worry that giving SQL Server more RAM will cause the context switching to rocket above 20k.

Can anyone give me a useful suggestion other than buying more RAM for my 5 year old server?
Duane LawrenceSQL Server database administratorAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

144 seconds on a busy system and 800-900 when idle sounds good to me. Why do you think this is related to the deadlocks?
Duane LawrenceSQL Server database administratorAuthor Commented:
Because the deadlocks happen as or just after the PLE drops.  I have Permon screen shots and times of the deadlock (with times) screen shots as well, but I can't post them here on Experts Exchange.  I will see if I can post them on my Linkedin account and provide a link.
Duane LawrenceSQL Server database administratorAuthor Commented:
I created a Google Docs presentation on Linkedin.  I hope that others can see it, the title is the same as this.

Duane LawrenceSQL Server database administratorAuthor Commented:
I read the Stored Procedure (SP) that updates the tables involved in the deadlocks.  It is inserting data, then it gets the ID "@NewID = SCOPE_IDENTITY()", then it calls another SP that then reads the row that was just inserted.  To make matters worse, when they read the row, they do joins to 2 other tables and don't use the other tables.  I am now negotiating to remove the "read what I just inserted" or at least remove the un-needed joins in the "read what I just inserted".  I spent two 12 hour days on this and I am very disappointed with the resistance I am getting to a no brainer question, do I cut the IO operations in half with a simple new philosophy?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Duane LawrenceSQL Server database administratorAuthor Commented:
I tested it on our test server after I made the modifications myself and it did indeed cut the IO operations in half.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.