locked
Running Azureus and eMule with DEMigrator operational causes 100% CPU usage RRS feed

  • Question

  • Looks like running P2P applications in console (remote desktop) session with DEMigrator service running will cause CPU usage to go to 100% and stay there. With eMule process manager will report 100% CPU Usage by demigrator.exe and with Azureus it's the Azureus.exe - however as soon as "Drive Migrator Extender" service is stopped, CPU usage drops back to normal levels.

    My system has a single 120GB Harddrive.

    Ideas, anyone?
    Monday, April 16, 2007 1:04 AM

Answers

  • Umm, I sort of hate to say it, but WHS is not designed to have software running in a console session.

    What's probably happening (and I would expect this to happen whether the file is open in a console session or over the network) is that every time your P2P client reads/writes this file, it has to go through Drive Extender.

    You could probably relieve the problem by adding another disk, but not allocating it to the storage pool in the WHS console. Instead, give it a normal drive letter and use it as local storage. Use that drive as your P2P target instead of the storage pool; if it's not in the pool, it's not managed by Drive Extender. You can even share portions of the drive out (or the whole thing) though, once again, it won't be managed by WHS.

    But the long term answer from Microsoft is likely to be that WHS is not designed to have applications run in a console session, so this is not a supported scenario.
    Monday, April 16, 2007 11:16 AM
    Moderator
  • Anneke, the recommended way to add drives to WHS is to add the drive to the storage pool. That way you don't have to manage the drive and contents separately from the rest of WHS.

    However, if there's some specific reason why you need to do this outside of WHS, you can log on to your server using remote desktop (use the administrator ID and the password you created when you installed/set up WHS), and then use the Disk Management MMC snap-in to assign a drive letter to the drive. If you have other identical drives, be careful to only modify the correct one.
    Monday, February 4, 2008 5:52 PM
    Moderator

All replies

  • The 100% CPU usage issue has been reported on Connect a bunch of times.  You can vote and add your issue to one of the existing cases there.  I would tend to think that this issue would be resolved by the time the product RTMs.
    Monday, April 16, 2007 1:36 AM
  • Yes, I realise that DEMigrator thing is a known issue in general, however in this particular case it only surfaces when I run a program that allocates and works with fairly large files (we're talking 300mb-1gb) with many small reads/writes. If I don't run anything in the console session, I don't tend to run into the DEMigrator issues. Is there an open issue you can point me to that is similar to what I'm experiencing?
    Monday, April 16, 2007 6:28 AM
  • Umm, I sort of hate to say it, but WHS is not designed to have software running in a console session.

    What's probably happening (and I would expect this to happen whether the file is open in a console session or over the network) is that every time your P2P client reads/writes this file, it has to go through Drive Extender.

    You could probably relieve the problem by adding another disk, but not allocating it to the storage pool in the WHS console. Instead, give it a normal drive letter and use it as local storage. Use that drive as your P2P target instead of the storage pool; if it's not in the pool, it's not managed by Drive Extender. You can even share portions of the drive out (or the whole thing) though, once again, it won't be managed by WHS.

    But the long term answer from Microsoft is likely to be that WHS is not designed to have applications run in a console session, so this is not a supported scenario.
    Monday, April 16, 2007 11:16 AM
    Moderator
  • Thanks, I sort of suspected this was the case. Drive Extender architecture (and WHS by extension) doesn't really lend itself to a scenario where there are constant reads/writes from an application running on the server. I appreciate the "official" answer.

     

    Some of the previous posters I've seen mentioned running a P2P application as a service instead of console session, but again I don't see how that would make a difference WRT Drive Extender. I guess the short answer is that Drive Extender pretty much nixes the chances of using a WHS-managed drive as P2P storage.

     

    Other than this issue I've had a pretty trouble-free experience so far.

    Monday, April 16, 2007 7:25 PM
  •  Ken Warren wrote:
    Umm, I sort of hate to say it, but WHS is not designed to have software running in a console session.

    What's probably happening (and I would expect this to happen whether the file is open in a console session or over the network) is that every time your P2P client reads/writes this file, it has to go through Drive Extender.

    You could probably relieve the problem by adding another disk, but not allocating it to the storage pool in the WHS console. Instead, give it a normal drive letter and use it as local storage. Use that drive as your P2P target instead of the storage pool; if it's not in the pool, it's not managed by Drive Extender. You can even share portions of the drive out (or the whole thing) though, once again, it won't be managed by WHS.

    But the long term answer from Microsoft is likely to be that WHS is not designed to have applications run in a console session, so this is not a supported scenario.

     

    How can I add another disk to the system and not allocating it to the storage pool of WHS.

     

    I add a disk but dit not find it in the system and in de WHS console is the drive ready to be add in the pool.

     

    I didn't find how to give de drive his drive letter.

     

    Thanks in advance. 

     

    Monday, February 4, 2008 3:11 PM
  • Anneke, the recommended way to add drives to WHS is to add the drive to the storage pool. That way you don't have to manage the drive and contents separately from the rest of WHS.

    However, if there's some specific reason why you need to do this outside of WHS, you can log on to your server using remote desktop (use the administrator ID and the password you created when you installed/set up WHS), and then use the Disk Management MMC snap-in to assign a drive letter to the drive. If you have other identical drives, be careful to only modify the correct one.
    Monday, February 4, 2008 5:52 PM
    Moderator
  •  

    When you add a disk to the server, the Console will ask you if you want to add the drive to the pool or not. If you say yes, it gets added to the remount point as extra storage space to your existing storage space and it doesn't get allocated a drive letter.

    If you answer 'no', the drive will not be added to the storage pool, so you will need to go into the Disk Management, MAKE SURE you have the correct drive, then format it and give it a drive letter somewhere down the alphabet.

     

    Colin

    Monday, February 4, 2008 5:55 PM