I really dislike this stupid java update scheduler already for a whole lot of reasons, but with windows 7 it’s an extra hassle, at least for me. This is because that new systray icons are hidden by default, so you can not notice the (stupid) thing running. Just now I started to use my laptop and realized it was very slow. Here’s why:
Total and complete #fail.
This past weekend I made a bunch of computer upgrades.
In my main machine, called TQM, it has been upgraded recently:
My upgrades are never limited to only one machine, so I also had some new goodies for my server, thor.
To confirm that trim is working and enabled in your windows7 install, go to the command prompt and type:
fsutil behavior query disabledeletenotify
DisableDeleteNotify = 1 (Windows TRIM commands are disabled)
DisableDeleteNotify = 0 (Windows TRIM commands are enabled
This guy is smart. His blog in general is a really good read.
Some very good ones are:
I run chkdsk.exe pretty often on my machines, mainly because I’m paranoid about data integrity since I have a lot of data spread across many hard drives. On my server I was trying to run chkdsk.exe on a couple of drives at once, thinking I could save myself some time.
When the machine slowed down to a crawl, I started by looking at the disk utilization to see what was going on. It was expected that this would slow down the machine, but these are non system disks, physically separate from anything that should directly impact system performance. After killing two of the three chkdsk’s, I was left with the one on the “J” drive, so I decided to check disk performance with the performance monitor.
Here you can see that aside from the chkdsk itself, there is some pretty significant writing taking place to the pagefile located on my “G” drive… Which shouldn’t take place since this machine has 8gb of ram and with no virtual machines running, never uses more than 1 gig. (No vm’s are running during all of this.) Of course, hitting the pagefile so much implies that the server is running out of memory, so let’s go see what the memory tab looks like.
Here you can see that there is 0 free memory (as in zero)! Then you can look at the processes and see that chkdsk.exe is using 7.0 gigs of memory! What? This must be a bug.. a leak.. right? Something must be wrong. Well, guess what? Apparently this is by design… from what I have been able to gather after reading various forums and blogs, the w7/2008 server version of chkdsk will use all the available ram in an attempt to speed up the chkdsk.
Here’s a Microsoft article that mentions it.
Now there has been a lot of sky is falling type talk over this subject, and there are many people who have stated that their machines crashed as a result of this. To be clear in my case the machine does continue to function, although it does it very slowly. In my opinion, this behavior, even if by design, is very bug-like and mimics a memory leak in every way, just without the crash at the end. (And the memory clears up when chkdsk is done.) This seems like an odd way for Microsoft to design this, and I would prefer some other way to limit the ram used by this process.
I have finally given in and put my stuff on Twitter. The stuff there will mostly be more tech in nature.
With IIS creating w3wp.exe’s for all of your apps (for which you have created a non default app pool) it is nice, but it’s impossible to tell exactly which is which. Microsoft includes a handy tool to do this with it’s in: %systemroot%\system32\iisapp.vbs (You may need to run it with cscript.exe if that’s not your default for .vbs).
Sample output:
C:\WINDOWS\system32>iisapp
W3WP.exe PID: 2028 AppPoolId: DefaultAppPool
W3WP.exe PID: 20224 AppPoolId: Autotransactiondocs
W3WP.exe PID: 17480 AppPoolId: IRAppPool
C:\WINDOWS\system32>
Oh, this is for Windows Server 2003 (and r2) only.. does not work with 2008 variants.
This seems like a simple thing, really, but every single place I have worked that developed .net code has had this problem, and for some reason, devs don’t seem to get it. (It has been an uphill battle everywhere I have found it with resistance from devs. Why??)
Usually the symptoms start out with scaling issues in production, you’ll see things like threads running out, connections not being closed, and general poor application performance. You can track these down and eventually you will find that in the web.config the setting “debug=enabled” is in there. It is this way because it is the default when you create a .net application. YOU DO NOT LEAVE IT LIKE THIS IN PRODUCTION. When you do, bad things happen, such as timeouts all being set to infinite. Here’s an article with a complete list and some more info.
Depending on whether or not your organization pushes the .configs with the applications (this is a religious discussion in itself.. I recommend not pushing the configs with every build for reasons like this), then when you do your next code push, the process repeats because of this value being set improperly again. The way to fix this for good is that in the production environment, you make a change to the machine.config to enable “retail” mode, which disallows debug from being enabled, regardless of what is in the application’s web.config.
<configuration>
<system.web>
<deployment retail=”true”/>
</system.web>
</configuration>
In my opinion, setting this in the machine.config should be part of the default build/installation/configuration of any production webserver.
I was trying to run the configure utility for the Solarwinds Orion MP for System Center Operations Manager 2007 r2 and getting a failure that told me to check the logfile. Where is the logfile? (It doesn’t say!) After much looking I found it in the .config in the folder for the management pack which is:
C:\Program Files\SolarWinds\Orion Management Pack for OpsManager 2007\OrionSCOMConfigApp.exe.config
Since they are using logforj for a standard .net app, it was easy to see. The value was:
<file value="${ALLUSERSPROFILE}\Documents\SolarWinds\Orion Management Pack for OpsManager 2007\ConfigurationWizard.log" />
On my system this translated to:
C:\Users\Public\Documents\SolarWinds\Orion Management Pack for OpsManager 2007\ConfigurationWizard.log
In our particular instance, the problem was:
Could not allocate space for object ‘dbo.ManagementPackStaging’.'PK_ManagementPackStaging’ in database ‘OperationsManager’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
This was resolved by opening the Microsoft SQL Server Management Studio and going to databases/OperationsManager, then properties, files, and increasing the initial size on the “PRIMARY” database file. Once I did this, I was able to configure the management pack successfully.
Powered by WordPress