SQL 2005 - Crashes when memory is increased

• InvisibleCat

  Default port

  Points: 1496

  More actions

  August 16, 2013 at 9:44 am

  #281182

  Hi,

  I wondered if anyone could help me with this, strange one and I've not come across it before.

  We have a server (Windows 2003 R2 SP 2 32 bit) that has 8GB of memory in it, SQL has 5.5GB allocated to it and SSIS processing takes about 1.6GB at it's peak (only runs overnight). We started to see high memory usage so we decided to increase the overall memory to 12GB. It's virtual so we did this and it all worked fine throughout the day, small SSIS packages ran without any issues, SQL had 8GB allocated to it and allowing for the 1.6 of SSIS usage that still leaves 2.4GB for the OS and other programs.

  However, our overnight load (SSIS package) then kicked in during the small hours and the whole server became unresponsive, no connectivity either via SSMS or remote desktop. The overnight runs an SSIS package and it just appears to have hung completely after running the first couple of steps. The services remained up (confirmed via Powershell) but nothing happened at all, no activity from the package and no connectivity, as soon as we could we rebooted the machine and rolled back the memory to 8GB and set SQL back to 5.5GB etc, restarting the job and it then completes as usual.

  It's bizarre that the package doesn't seem to be able to work with a machine with 12GB, I've never seen anything like it.

  Has anyone ever encountered anything like this before? Or even has any idea where I could look. Interestingly the event log does make reference to;

  "Process 51:0:0 (0x148c) Worker 0x78C600E8 appears to be non-yielding on Scheduler 2. Thread creation time: 13021063245072. Approx Thread CPU Used: kernel 31 ms, user 0 ms. Process Utilization 0%%. System Idle 99%%. Interval: 89018 ms."

  I did find this possible cause - http://support.microsoft.com/kb/922658 but our server is SP2 so I don't think this is applicable.

  I also found this - http://support.microsoft.com/kb/949595 - although the timings don't match up on the stack dump to when the issues occurred - either way we need to get patched up.

  Thanks in advance,

  Nic

  P.S - The instance is running SQL 2005 SP2 (I know it should be on SP4 and I'm working on that).