Will Workgroup PDM 2010 work with previous versions of SolidWorks?
I'm also wondering if the support for the /3GB switch will help very large vaults crashing...
The standard response from SolidWorks is; PDMW is supported with an earlier version of SolidWorks as long as the difference is no greater than 1 year/version. In theory PDMW 2010 will work with SolidWorks 2009, but not SolidWorks 2008.
As far as the switch goes, 2010 What's New says the switch is supported with PDMW, it's pretty easy to turn on and verify if it makes a difference. I would turn on regardless.
I've alway found that restarting the vault periodically (once a week) helps performance.
The only reason that I really ask is that, I've got a client that is using Workgroup PDM 2009 Server on a 64-bit machine with 20GB of RAM. Unfortunately, the service CRASHES constantly and throw these kinds of errors:
pdmwRequestHandler::ProcessRequest (CMemoryException) Error: Out of memory.,
even though only uses 2GB of RAM.
One big problem is that PDM 2009 is only 32-bit service...
I wonder if 2010 is a TRUE 64-bit app (probably not).
And even if not, if I use the /3GB switch, will they hit a memory limitation or still have the errors?..
Exactly! What I really meant was:
Should I move the vault to a 32-bit computer, use the /3gb switch, and allocate 4GB to applications. If so, will I have the 'memory issues' that I've been experiencing? (rhetorical question)...
Ideally, I'd love to see SW compile a true 64-bit version of pdmwserver....But I won't hold my breath..
I don't see why not, after all you can't really make very good use of the x64 OS + 20GB RAM using PDMW.
I still see you restarting the vault every week or so to overcome the memory leakage.
These days, the Client /Server Yr and SP should go hand in hand.
Is the vault installed locally on the machine with 20 GB of ram or just the workgroup client?
Is the vaultdata directory on the same machine as the service and is it on a system drive or a network appliance (SAN, NAS etc)
If the PDMWorks Service is on a Windows 2003 server; it should be at SP2 and an addtional hotfix (solution
S-02635) needs to be applied.
How large is the server.log file? It sould be maintained no larger than 1 MB
Use the vaultAdmin Tool to save and clear it. While there make sure place a check in the box above the validation radio buttons to make sure they engage when the service is restarted.
Restart the service.
If you still have the issue, get your VAR in the loop.
The Vault is installed on Windows Server 2003 R2 and that machine has 20GB of RAM.
The Vaultdata is on the same machine.
We've cleared the log files (i.e. deleted it) and we've re-validated the vault.
As it stands, the service (pdmwservice) only uses a MAXIMUM of 1GB of RAM (idles around 600K)
We've taken the vault and split it up into two separate vaults on two separate machines.
Unfortunately, the vault crashes quite often (2-3 times a day).
Ther errors include:
I can't tell if its the shear number of files (~55k), the number of projects (~300), or the number of active users.
Luckily, we've set the service to automatically restart but it takes 15-20 minutes to validate, everytime it crashes.
We've got the VAR (and SolidWorks) in the loop and there is no solution. This problem has been going on ever since 2007. The recent solution offered (upgrading to 2009) offered no help/resolution.
Typically while Solidworks will support one version back there have been increasing issues with running versions that are not congruent. As a VAR I have seen a lot of 'server errors' for clients when the server and client do not match the major/minor version. For this reason we typically recommend that you maintain congruent releases.
As for your crashing issue, while workgroup server is not a 64bit application, there is nothing that limits it to a point where it would function different on a 32bit machine from a 64bit for memory allocation (at least that I have ever seen in my years of dealing with Workgroup, and we have a customer that runs a vault close to a terabyte). I would review the application/system logs for further information on the crashes. The memory related errors could be an issue with a dependancy of the server.
Do you have event logs that you could post for review?
Retrieving data ...