dasd high CPU and memory problem on macOS

What is dasd on Mac?

One of the peculiar things about macOS performance issues is that the process at the top of Activity Monitor isn't necessarily the true culprit. A case in point is an entity named dasd, which may suddenly start consuming a hefty amount of CPU, RAM, or both. The knock-on effect is predictable: the Mac runs hot, fans may ramp up, battery life takes a nosedive, and everyday actions feel unusually sluggish. In particularly bad scenarios, memory consumption keeps growing until macOS begins relying heavily on swap or throws an "out of application memory" warning. Seeing an obscure daemon gobbling up resources naturally raises a red flag, but dasd itself is a legitimate part of the operating system.

The name stands for Duet Activity Scheduler daemon. Its executable normally resides at /usr/libexec/dasd, and the process is managed by launchd as part of macOS. Rather than doing all the background work itself, dasd acts as something of a dispatcher. It keeps track of deferred activities submitted by system components and applications, evaluates whether the conditions are right for them to run, and gives eligible tasks the green light. Timing, power conditions, thermal state, and other policies can factor into this decision-making routine. In a healthy system, you barely notice any of that. Things get interesting when a task keeps getting submitted or rescored in a loop, at which point the scheduler that is supposed to optimize background activity can become a resource hog instead.

Why dasd starts using excessive CPU and memory

Under normal circumstances, a brief spike in dasd activity is no cause for concern. Your Mac has scores of background jobs to coordinate, particularly shortly after startup, login, an operating system update, or reconnecting to the Internet after being offline for a while.

Persistent load is a different story. If the process stays near the top of Activity Monitor for an extended period or its memory footprint keeps climbing without coming back down, something in the scheduling chain has probably gone sideways.

Common triggers include:

• A background activity caught in a scheduling loop. A service may repeatedly register a job whose execution conditions are already met or whose deadline is in the past. dasd processes the request immediately, receives essentially the same one again, and the cycle continues.
• App Store background activity. appstoreagent is one process worth keeping an eye on. There have been scenarios where an App Store-related job was resubmitted continuously, causing both appstoreagent and dasd to use abnormal amounts of processing capacity.
• Apple Intelligence and related background services. On newer macOS versions, processes such as BiomeAgent can submit deferred tasks through the same scheduling machinery. A bug higher up that chain may consequently make dasd look like the offender.
• A glitch after a macOS update. Major upgrades and some incremental updates can entail considerable housekeeping behind the scenes. Scheduling databases are rebuilt or revisited, services register fresh activities, and old state has to mesh with the new system version. An inconsistency at this stage may send the daemon into overdrive.
• Corrupt or stale background-processing data. macOS maintains databases used for power, performance, and deferred activity management. If relevant state becomes malformed, the scheduler may keep reevaluating jobs that never transition cleanly to their next state.
• A misbehaving third-party application. Apple's own services aren't the only software capable of doing background work. An outdated or buggy program that continually requests execution can indirectly keep the system scheduler busy.

There is another detail that can be confusing if you are examining the CPU tab in Activity Monitor. A process can show a CPU figure greater than 100%. That doesn't mean macOS has somehow invented extra processing power. Activity Monitor treats a fully utilized CPU core as roughly 100%, so a multithreaded process engaging more than one core can exceed that figure.

Memory behaves differently. A temporary increase is normal, but dasd swelling into several gigabytes and continuing to grow is definitely out of character. Some pre-release versions of macOS have exhibited especially dramatic manifestations of this problem, with the daemon consuming tens of gigabytes of virtual memory before the system intervened.

How to fix dasd high CPU and memory usage on Mac

There is no good reason to delete or permanently disable dasd. In reality, doing so would attack the messenger rather than the source of the problem. The following troubleshooting sequence starts with harmless measures and gradually moves toward more technical diagnostics.

1. Make sure the resource spike is actually persistent

The first thing to establish is whether you are dealing with a bug or simply catching macOS in the middle of legitimate housekeeping.

1. Open Finder and go to Applications > Utilities.
2. Launch Activity Monitor.
3. Select the CPU tab.
4. Click the % CPU column to sort processes by processor usage.
5. Find dasd and watch its activity for several minutes.
6. Switch to the Memory tab and check the same process.
7. Pay attention to Memory Pressure at the bottom of the window as well.

If dasd briefly goes up and then settles down, there probably isn't anything to fix. This is particularly true soon after restarting the Mac, installing an update, connecting the computer to power, or waking it after a long sleep.

Things look less benign if CPU consumption stays consistently high, RAM usage rises continuously, or the Memory Pressure graph turns yellow or red.

2. Force quit dasd and see what happens

Restarting the process is a reasonable first troubleshooting move. It clears the current daemon instance without attempting to remove a macOS component.

1. Open Activity Monitor.
2. Type dasd into the search field.
3. Select the process.
4. Click the Stop button in the Activity Monitor toolbar.
5. Choose Force Quit if a regular quit doesn't work.
6. Enter administrator credentials if macOS requests them.
7. Watch Activity Monitor for a few minutes.

Don't be surprised when dasd comes back. It is supervised by macOS, so the system can launch a fresh instance automatically. That's expected.

The interesting part is what happens next. If the newly started process stays quiet, you may have cleared a one-off scheduling hiccup. If it immediately shoots back to high CPU or starts accumulating memory again, an upstream task is most likely feeding the loop.

3. Restart the Mac

It sounds elementary, but there is a good reason to try a full reboot before moving into Terminal territory. Restarting resets the current set of processes and forces macOS to rebuild the active scheduling environment.

1. Save all open documents.
2. Click the Apple menu.
3. Select Restart.
4. Let the Mac boot normally.
5. Wait a few minutes after signing in before opening Activity Monitor.
6. Check dasd again under both CPU and Memory.

If the problem appears only after the Mac has been awake for many hours or days, this is useful information in itself. It points more toward an accumulated scheduling state or a recurring background task than an inherently broken system daemon.

4. Install pending macOS updates

A system-level scheduler is tightly coupled with numerous other macOS components. This makes operating system updates especially relevant when dasd begins misbehaving after a new release or upgrade.

To check:

1. Open System Settings.
2. Select General.
3. Click Software Update.
4. Install any available macOS update.
5. Restart the Mac afterward, even if the installer doesn't explicitly insist on another reboot.

If you are running a beta version of macOS, the importance of this step goes up several notches. Memory leaks involving system daemons can be build-specific, and no amount of local tinkering is as clean a solution as installing a version in which the underlying bug has been corrected.

From a broader perspective, beta operating systems are a questionable fit for a Mac that you depend on for daily work. Bugs in invisible services such as dasd are precisely the sort of rough edge that pre-release software can expose.

5. Look for the process that is keeping dasd busy

Here is where troubleshooting gets a little more interesting. Since dasd schedules work for other components, another process using excessive CPU alongside it can provide the missing clue.

Open Activity Monitor, sort the CPU list, and look at what is sitting near dasd. Pay particular attention to system processes such as:

• appstoreagent
• BiomeAgent
• softwareupdated
• backupd
• iCloud-related services
• third-party application helpers or background agents

The presence of one of these processes does not automatically mean it is broken. What matters is an obvious correlation: dasd spikes at the same time as another background service, both remain busy for an unusually long stretch, and the pattern returns after you restart one or both.

If appstoreagent is consuming lots of CPU, for instance, close the App Store if it is open and restart the Mac. You can also select appstoreagent in Activity Monitor and quit it. macOS will start it again when required.

For a third-party program, quit the parent application and see whether dasd settles down. If it does, update that app before launching it again.

6. Review Login Items and background applications

Software that automatically starts with macOS is another area worth checking. Some applications remain active long after their visible windows have been closed, and their helper processes can continue submitting background work.

1. Open System Settings.
2. Go to General > Login Items & Extensions.
3. Review the apps listed under Open at Login.
4. Check the software allowed to run in the background.
5. Temporarily turn off nonessential third-party items.
6. Restart the Mac.
7. Check whether dasd still runs amok.

Don't disable everything indiscriminately. Cloud storage utilities, security software, password managers, and hardware support tools may provide functionality you rely on. The idea is to narrow down the culprit methodically rather than carpet-bomb the startup configuration.

7. Check dasd activity in the macOS log

Activity Monitor tells you that something is happening. The unified macOS log can give you a better idea of what that something is.

Open Terminal from Applications > Utilities and run:

log show --last 10m --style compact --predicate 'process == "dasd"' --info

This command displays dasd messages recorded during the previous ten minutes.

The output can be quite dense, so there is no need to make sense of every line. Look for a repeated activity identifier or the same sequence appearing over and over again. Entries suggesting that an activity is being submitted and immediately run hundreds or thousands of times are far more meaningful than sporadic housekeeping messages.

If appstoreagent is also suspicious, you can broaden the query:

log show --last 10m --style compact --predicate 'process == "dasd" OR process == "appstoreagent"' --info

The name attached to a recurring request may reveal which service is triggering the loop.

I wouldn't recommend modifying hidden preference values merely because an obscure activity identifier shows up in these logs. Such fixes tend to be version-specific, and a command that works around one macOS bug may be irrelevant to another.

8. Boot into Safe Mode

Safe Mode is useful when the available evidence points toward third-party software but doesn't reveal which application is responsible. It starts macOS with a more restricted collection of extensions and startup components.

On an Apple silicon Mac:

1. Shut down your Mac.
2. Press and hold the power button until startup options appear.
3. Select your startup disk.
4. Hold the Shift key.
5. Click Continue in Safe Mode.
6. Sign in and inspect dasd in Activity Monitor.

On an Intel-based Mac:

1. Restart the computer.
2. Immediately press and hold Shift.
3. Release the key when the login window appears.
4. Sign in and check Activity Monitor.

If dasd behaves normally in Safe Mode but goes haywire after a regular boot, a third-party background component becomes a much stronger suspect.

Restart normally afterward to leave Safe Mode.

9. Verify that the process is the genuine macOS dasd

A process name alone isn't proof of legitimacy. Malware can theoretically adopt the name of a legitimate service to blend into Activity Monitor, although that is not the typical explanation for this particular problem.

You can check where the running process comes from with Terminal:

ps -ax -o pid,command | grep '[d]asd'

A genuine macOS instance should point to:

/usr/libexec/dasd

If a process called dasd originates from a user directory, an unfamiliar application folder, /tmp, or another odd location, that is a completely different scenario and deserves a security investigation.

Do not delete /usr/libexec/dasd. The copy at that path is an Apple system component.

10. Reset PowerLog data only as a last-resort workaround

There is a more aggressive workaround that has helped in cases where dasd developed an extreme memory leak tied to background-processing or power-logging state. This should not be your first move, particularly on a stable macOS installation.

Before proceeding, save your work and make sure important data is backed up. Then open Terminal and run the following command exactly as written:

sudo rm -rf /private/var/db/powerlog

Enter the administrator password when prompted. Terminal won't display the password characters as you type them, which is normal.

Next, restart the Mac:

sudo reboot

This removes local PowerLog data that macOS can recreate after startup. It does not delete your documents or applications, but it does discard system power-history information and should therefore be viewed as troubleshooting rather than routine maintenance.

More importantly, this workaround is not universal. It has helped with specific manifestations of runaway dasd memory usage, while in other cases the issue eventually returned because the underlying bug was somewhere else. If a regular macOS update is available, installing that update is the preferable remedy.

Should you disable or remove dasd?

No. There is a considerable difference between force quitting dasd once to reset a stuck instance and trying to disable it permanently.

The daemon sits in the middle of macOS background scheduling. Interfering with it at the system level may delay or disrupt maintenance activities, backups, security tasks, software update routines, and other jobs that are supposed to run when conditions permit. On modern macOS versions, system protections also make tampering with Apple-supplied components deliberately difficult.

To recap, dasd is normally part of the solution rather than the problem. If it starts gobbling up CPU or RAM, the better question is what activity has pushed the scheduler into that state.

How to prevent recurring dasd performance issues

You cannot prevent every macOS bug, especially one that originates in Apple's own background services. That said, a few habits significantly reduce the number of variables involved when the problem occurs.

• Keep macOS up to date. Scheduler and memory-management bugs are exactly the sort of system-level problems that maintenance releases can fix.
• Keep third-party software current as well. Outdated background agents may rely on behavior that has changed in a newer version of macOS.
• Think twice before running beta macOS builds on a production Mac. Pre-release software can contain memory leaks and scheduling bugs that are largely outside the user's control.
• Review Login Items periodically. There is little benefit in allowing software you rarely use to keep helper processes running around the clock.
• Maintain adequate free disk space. This won't fix dasd, but macOS needs storage for swap when memory pressure rises. A nearly full drive makes any runaway-memory problem considerably more painful.
• Avoid disabling Apple daemons based solely on Activity Monitor readings. High resource consumption is a symptom. Identifying the component generating the workload is a more durable approach.
• Check Activity Monitor after major system changes. If a new macOS release or application update introduces the problem, knowing exactly when it started can save a good deal of troubleshooting later.

Conclusion

For such a short and cryptic process name, dasd has a surprisingly important job. As the Duet Activity Scheduler daemon, it helps macOS decide when a wide range of deferred background activities should proceed. This normally happens quietly enough that most Mac users never have a reason to learn the process exists.

Sustained CPU load or runaway memory consumption is not normal, though. Start by restarting the daemon and the Mac, install pending updates, and look for another process that is repeatedly feeding work into the scheduler. Activity Monitor and the unified log can usually narrow things down without resorting to invasive system changes. And unless there is evidence that a process carrying the same name resides somewhere other than /usr/libexec/dasd, there is no reason to treat the genuine Apple daemon as malware.

FAQ

Is dasd malware?

Is it safe to force quit dasd?

Why can dasd show more than 100% CPU usage?

Why is dasd using several gigabytes of memory?