We have a Serv-U MFT server that is being backed by a SQL 2014 database for users/groups. This will be deployed as a clustered configuration for Serv-U so the DB is required. The problem I am having is the everything works great with a couple users in the database but when we load the 5000 we need to, it tends to lock up the servu application for around 10 minutes. The ServU server has 12GB of memory and 2 vCPUs (in vmware).
Has anyone had this behavior and possibly know how to fix it?
I have the same issue. The official response from Serv-U is to limit the number of users in each collection to 100 users. If you capture the background SQL commands going on when you enumerate your users you will see why it is so slow. As we can't just dump a few thousand paying clients here we just try and do what we want directly in the SQL database itself.
I too hope they resolve the problem as it can take up to 20 minutes to make a simple user account change in the Serv-U Management Console. Their only other solution was to dump SQL and try LDAP but due to the hundreds of hours required to implement that change it isn't something we have decided to do just yet and will most likely spend those hours migrating to a better product instead.
This has been a known issue in Serv-U since before I starting working for Rhinosoft (who originally wrote Serv-U). From the original KB:
"Collections in Serv-U are a way of logically organizing users and groups to reduce load times when managing users in the Serv-U Management Console. Unlike Groups, User Collections do not offer any level of configuration to the User accounts they contain. Instead, they simply offer a way to organize users into containers for ease of viewing and administration. ... Using Collections also reduces load times for user management when dealing with hundreds to thousands of users. By keeping each Collection down to ~100 users, load times are minimized and it is easier to manage users within your Serv-U installation. "
At the time, the product management decision was to optimize Serv-U's integration with Microsoft AD (including its NTFS permission structures and eventually groups) instead of its integration with DBs. Part of the reasoning that went into that decision was that many of our traditional DB integrations occurred when ISPs and other organizations wanted Serv-U to tie into their existing (and externally managed) DBs full of users. The other part was that enterprises were flocking toward AD not just for ease of adding ("provisioning") users, but ensuring that they had a single "kill switch" that would turn accounts off ("deprovisioning") as soon a user was disabled in the master AD.
Realistically, your best course of action to work with a lot of Serv-U users in a DB may be to inspect the DB schema and build your own management interface because, like I stated, a "custom" level of integration was one of the assumptions Serv-U's DB feature was built on.
Are you a Certified File Transfer Professional (CFTP) yet?
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.