Okay, I think I've just managed to fix mine so here's a full break down.
We're building a new application which we put through system test, then user test before eventually sending it live. In user test we have 3 servers, one for the web interface, one for the web services and another with SQL 2005.
The code dropped on to the box has already been through system test so I knew the code wasn't the issue.
Our websites and web application sites all run in their own application pools with their own user service accounts and I noticed that one of the application service sites W3WP process was running between 600mb and 1.3gb. Once it reached the upper limit it would recycle and lose all the session state but the bigger problem was that the service was unacceptable as the server ran like a dog (with broken legs).
I changed the application pool to the default app pool and the memory sat at 40mb, great. So I tried to create a new application pool but it went back to it's original state. I then tried the original application pool but using the Network service account and again the application sat at 40mb.
Long story short, it ended up being the user account that the service was using that was causing the issue which sounds bizarre but it looks all good at the moment.
If you're already using the Default App pool then I'm not sure if creating a new application pool would fix anything, maybe just create a service account and give the necessary rights 'n' stuff and it should work :)