What are the detailed hardware specifications of your servers and your network environment?
Our servers specifications:
We the disks in a Sun linked by fibre channel.
We are already in contact with SolidWorks trough our vendor.
We are trying to detect what is the problem that originates the crashes and the poor performance.
SolidWorks send us already two hotfixs to correct problems like "Clear Local Cache".
So, no one has the same performance problem?
I can't find a solution for this problem.
We have a network 1GB, we are starting defrag the disk, but problems persists.
Let's wait for the SolidWorks answers, but we are already tired of wait.
We need solutions quickly.
We have some issues for SD/PDM 2010 SP 2.1. some are closed and some are still open. At the moment we are waiting for SP4 of PDM/SW because SP3 wont solve our problems.
Her are some of our worst SPR:
Pedro, if your 5 vaults are replicated, then this may be useful...if not, then disregard but maybe it will help someone.
Guys I am a little late to this conversation but I would like to inject a good deal of my EPDM vault replication experience and connectivity information into the discussion if it's ok. It's long but may shed some light on your slow experience, hopefully.
Late last year (2009), I researched replication as an option for implementing EPDM at our other business units across the country to create a more collaborative engineering environment and foster more cohesion while saving costs and using EPDM vault replication.
IT and I ran tests with a remote office 60 miles away to determine average latency times and lost packets using wireshark and smokeping. The numbers looked good and gave us insight into how the EPDM infrastructure works so we thought. We were told by our VAR that if the replicated site lost connection with the host site then they could still work in the vault and when connectivity is restored, the replication would pick back up where it left off.
In January this year I implemented a replicated vault at one of our offices 3 states away and bulk loaded their data, created data cards, created variables, added all users, wrote some VB Scripts to handle a little automation, and created an ECO workflow with auto updating Word document fields. Good right?
No, the connection latency values are averaging 200ms and lost packets are around 2-5% sustained daily.
This translates into a horribly slow vault browsing, get latest version, opening, copying, transitioning, etc. vault experience.
Last month we experienced a loss of connectivity with the remote replicated office and learned they were unable to work in their vault. After testing with the data trying to determine what was wrong, discovered a few things.
- The PDM vault was designed to store the files in the replicated archive server locally to the replicated office yes, however we have discovered the replicated server runs a query against the host database server where the file metadata is stored anytime the replicated vault is navigated i.e. browsing, previewing files, transitioning files, creating PDFs using tasks, check in & check out, getting latest version, etc.
- The challenge becomes evident when the folder contents are populated. Each time a folder is clicked, the replicated archive server queries the host database server and returns the contents which can cause the folder population to take literally 2-3 seconds to build the view. This is just to build the folder view, this time doesn't include browsing, transitioning numerous files, creating PDFs using tasks, checkin/checkout, getting latest version, etc.
- Latency is not a devastating problem but it is annoying. However, with high number of lost packets the data being replicated can eventually become corrupt which could harm data integrity little by little theoretically.
- I created a quick video that has helped our replicated vault office browse the vault faster which basically pushes the host database server query back until the last possible moment. Take a look at the attached video.
- Work with your ISP to get a dedicated line for your VPN to the remote office in order to decrease latency below 75 ms and reduce the % of lost packets to <0.5% daily sustained.
- Work around the limitation until you can purchase another SQL server for the host office and break it into a stand alone installation. The PROBLEM is that the license file you have now is tied or node locked to the SQL server and cannot be broken into separate license files for individual remote sites. BUMMER! So we will be investigating this further and perhaps talking with our legal department about purchasing new licenses for our remote site once we fund the new SQL server.
*I think replication is a good idea poorly implemented...*
The video is meant to be viewed using Internet Explorer so if given an option to open it using some program, choose that.
If you have difficulty viewing the video, download and install the Adobe Flash player and run it again…
This “should” help!
Good write you did. We have been havig access time problems at sites in other countries.
If I read your post right, one of the options you mention is putting a db server at each site. How do these (db) servers stay in sync? What happens when these sites are sharing files live (such a one person at each site viewing and reviewing a single file)? I'm not an IT guy, so maybe this is an novice type question.
I haven't read everything here, but to quickly answer your question, you use replication. You set up a schedule that fits the traffic pattern and that way the other servers are updated per a schedule. And if someone needs a file that has not yet replicated, then it pulls it on demand.
We've been replicating the archive servers for a few years - it was the database server I was wondering about. I've always been under the impression you just don't replicate the database server.
Ok, so that's what I get for not reading - you can't replicate the database server as far as I know. Yes, it's the archive server that gets replicated. Sorry for not paying attention before I spoke - tried to answer in a hurry. :-(
It's good to know that replication works well.
We haven't yet replicated our EPDM. We thought to do the replication with a site in Ireland but we cancelled the idea.
In our case, we have performance problems, error's, features doesn't work well (like destroy items in recycle)... etc without replication.
Until the moment I haven't an answer about the problem, neither from our vendor (because they are dependent from the SolidWorks answers/solutions) neither SolidWorks.
Thanks for intent to help! ;.) That's what I thought too about the db server..
My apologies on the radio silence, I haven't had time to log in and respond! That's horrible!!
Thanks for the kudos on the write-up. You can replicate the database server or the SQL Server by clustering them then replicating the Vaults becomes easier. This is a very complex operation from what I understand and we haven't attempted to pursue that.
SolidWorks recommends >1.5mbps speed with less than 20% packet loss as the minimum requirements for replication so we have bumped up the internet connection speed at our replicated sites so the slow performance problem is no longer an issue. We are having success with this PDM model.
I hope this helps.
Have you had any sucess with database replication?
Wait, after re-reading your post, no we have not replicated the database using the clustering as I mentioned above. We are only replicating the vault servers. As long as the internet connection speed and packet loss values are above the recommended spec from SolidWorks, we don't have issues.
I hope this answers the question.
Was told me that almost of the problems performance and EPDM bug's (like the action destroy) will be solved in EPDM SP5.
We are also experiencing some of the same performance issues you are as well as licensing issues (licenses not being released).
We have 3 Vaults with a total size of just under 300GB
Our Vault server has dual Quad core E5320 Xeon Processors running at 1.86Ghz and 8GB of RAM
Our SQL 2005 Server has dual Quad core E5320 Xeon Processors running at 1.86Ghz and 16GB of RAM
We are working with our reseller on the license "releasing" issues that were supposed to be fixed in SP3 but we can show that they are in fact not being released.
We are NOT replicating data.
Hello everybody again,
So, in january I have upgraded the PDM for version 2010 SP5 and the problems... continue.
I'm still working with my VAR in a solution for these problems and waitting that SolidWorks find a solution.
1 person found this helpful
The problem of PDM performance has been solved and the cause was the option "Show inherited values in folder card edit page" on user settings. Without this option checked, the PDM is very fast
Thank's to Sqedio (my VAR) and Soliwork's company that have found the solution (very simple but very hidden) of our problem.