• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 62 subscribers
  • Views 3513 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Set-QadUser -Proxy and high CPU usage

Lethe
over 5 years ago

Hello all, 

before opening an SR for this I was wondering if anybody else experienced this, as per subject I have a bunch of scripts performing updates on the users in bulk (it can be anything from 30 to 1000+ users) no workflows or anything attached just "one time scripts" required from time to time and whenever I use the Set-QadUser -Identity $something -objectAttributes $myhash -Proxy CPU on the server running the admin services spikes up to 80/90/100% usage and stays that way even long after the script has done running, same goes the consumed memory. 

Keep in mind the above is just an example I can update 1 or 10 attributes and result is the same, server has 8 CPUs and 16gb Memory which is fine most of the time apart from when I perform such bulk changes, keep in mind this seems to affect only changes on Virtual Attributes as I perform bulk updates on native AD attributes there is no such performance hiccup.

Do I have a way to reduce cmdlets footprint? Anybody else faced a similar issue? As I said before filing an SR I would like to hear other admins experiences as well. 

Thanks in advance for any pointer/help.

Parents
  • 0 over 5 years ago

    One thing that might help is to not use the -proxy in each call but rather, a persistent session.  This is how I do it:

    $ARConnection = Connect-QADService -proxy

    import-csv "somedata.txt" | %{

    set-qaduser -connection $ARConnection -identity $_.username -Description $_.Description

    }

    You don't NEED to do the -connection thing, you could simply start your script with the Connect-QADService and persist a connection that way as all subsequent commands in the same script will use that same AR server session.  This is just a coding style thing for me to show that you are using a persistent connection.

    One other consideration is that in the Connect-QADService line, you could specify a -Service <AR server name>.  I offer that up as a way of potentially allowing you to "load balance" your scripts across different AR servers.

  • 0 over 5 years ago in reply to JohnnyQuest

    Thanks, yes I of course use the -Proxy parameter only where absolutely necessary.

    We (ab)use automation given the size of our AD so I have lot of other frameworks/workflows/scripts building on top of ARS VA so the -Proxy connection for us a is a must as have no other way to expose all the custom attributes we're manipulating. 

  • 0 over 5 years ago in reply to Lethe

    You're welcome.  I guess my point is that it always amazes me how much overhead the use of the -proxy switch imposes and how much faster a script will run when you use a persistent session to the AR server instead.

  • 0 over 5 years ago in reply to JohnnyQuest

    Yep completely agree with your statement. 

    We have scripts updating 20k+ users for each run and at the same time doing lot of computation of action to be taken and that goes smoothly without any flicker from the server as we only update native AD attributes, whenever it boils down to persistent connection this happens... 

    It's a pity as I love the entire idea of having virtual attributes which makes my life much easier as, before ARS, I needed to handle schema updates from time to time just for the purpose of this automation. 

    Well I will keep looking and will open an SR and if anything comes up I will post back here.

Reply
  • 0 over 5 years ago in reply to JohnnyQuest

    Yep completely agree with your statement. 

    We have scripts updating 20k+ users for each run and at the same time doing lot of computation of action to be taken and that goes smoothly without any flicker from the server as we only update native AD attributes, whenever it boils down to persistent connection this happens... 

    It's a pity as I love the entire idea of having virtual attributes which makes my life much easier as, before ARS, I needed to handle schema updates from time to time just for the purpose of this automation. 

    Well I will keep looking and will open an SR and if anything comes up I will post back here.

Children
No Data