Logic often very sluggish - lsof process [SOLVED]

Hi All

I'm having a frustrating problem.

Usually I work exclusively with software instruments where there are no issues, but every now and then I'll have fairly meaty audio projects. The audio files are usually pretty long - an hour plus live recordings - and can run to 40+ mono tracks. I put all audio on an external drive (either G-Drive or a Lacie) and everything will be running swiftly until the process (as noted in Activity Monitor) "lsof" starts. Things then start to crawl for about 20 seconds or so and then all is fine again. It is VERY frustrating! The process takes 98-99% processor resources and happens every 2 mins or so.

I've googled for a solution obviously and there are other people with problems but nothing for Logic that I can find. The process appears to be initiated by Logic as it only appears in the Activity Monitor log when I'm working on it and not otherwise. I'm reluctant to mess with Terminal as some suggest. Maybe it's just a case of updating the OS (currently Sierra 10.12.6) but I'm reluctant to do that without a gap in work.

To summarise:

Problem only seems to present itself whilst using audio; the files themselves are pretty long - 450MB each with often over 40 of them. On my system "lsof" is activating whilst working with Logic. Files are on external TB2 drive, when I move to internal drive (hybrid drive) things improve a bit but only a bit; Slows to almost totally unresponsive. Feels like a fairly newish problem although I can't be sure when it started.

System details:

Logic Pro 10.4.4

I/O Buffer 128 Samples

iMac Retina 27" Late 2015

4GHz i7, 64GB RAM

macOS: Sierra 10.12.6

External Drives

G-Drive 2TB Partition on 4TB Thunderbolt 2 Drive

Lacie 2TB Partition on 6TB Thunderbolt 2 Drive

Universal Audio:

Thunderbolt 2 Interfaces

2 x Apollo 8 Quads - 1 black, 1 silver

2 x UAD-2 Satellite Quads

Example copy/paste from Activity Monitor of the process:

lsof 98.9 13.82 1 0 82866

That's: name: CPU%: CPU Time: Threads: Idle Wake Ups: PID

Any help gratefully received!

Cheers

Chris

That is a very good question...

Just had a look: the audio threads (all 8 of them) are barely doing anything at all, either when the lsof process starts or when it stops, i.e. no noticeable difference. The I/O is peaking about 60% but averaging about 33% when lsof is not on. Again, can't see much difference when the lsof process happens. Maybe if I'm being really picky the I/O activity increases... but certainly not significantly.

Thanks for the reply

Chris

Nope, SATA 7200 rpm

Spinning drives on Thunderbolt 2? And partitioned as welll?That makes more sense now.

That’s a waste on T2 bandwidth.

You wanna use SSDs instead, especially with those huge files. And avoid partitions. Makes the drive work more.

OK, sounds like a good excuse to get some heavyweight SSDs but what of the mysterious lsof? I get the impression it's a housekeeping process, indexing or something? Is it just something I'm noticing because of the size and number of files, and being amplified as a problem by using SATAs?

Is lsof a system thing that happens all the time and I'm just noticing because of these circumstances or is it rogue? Like I say, there are long periods where all works smoothly and quickly and then grinds to a halt

Thanks again for the help

Chris

'lsof' is a command line tool that lists open files. I have no idea why Logic would be running that tool, but it might be some background information gathering for the audio.

As others have suggested an SSD would probably help. The issue with spinning drives is 'access time' which involves rotational latency and seek time (moving the heads to the right track). No spinning disk is going to help you. Doesn't matter the RPM or the transfer rate. The machine is waiting for the disk to get into position to read.

Assume - best case - that the average access time is 5 ms (milliseconds). It will be worse, but the demonstration is easier. Best case the disk can access 200 chunks of data in any given second. Add transfer time etc. Let's be generous and say that any chunk of audio you want can be had in 6 ms. 166 chunks of data per second. 40 files means you can get a whopping 4 chunks of data per track per second. You probably can see where this is headed...

I ran into trouble with external disk, USB3, when working with 30+ audio files. The transfer of data isn't the problem, the USB3 bus can handle it. The disk drive just can't get to your data fast enough. I get better results putting my large multi-track projects on a server Mac (1GB Ethernet connection) and running them from there. Project files on server are on an SSD. Works fine.

The only possible workaround would be to split the tracks between multiple disk drives, but that's just a complete nightmare.

I have recently begun the switch from external spinning hard drives to SSD for working disks. Get a nice 1TB SSD (SATA speeds are fine) and a $10 adapter, plug in to a USB3 port, smile and go about your business.

In the not too distant future (when NvMe prices come down) I will be growing in to 2TB NvME with appropriate connectors and expecting 800-900MByte/second transfer speeds to accompany my less than .2 ms access times - easily 20 times faster than the old technology.

And thanks Facej for the comprehensive answer, really helpful.

Yes, all makes sense and feels like a good idea to get hold of a few SSDs exclusively for audio. I suppose the only thing that still confuses me slightly is that everything will happily run smoothly - no glitches, no slowing - until lsof starts despite the dinosaur drives. But maybe the sheer size and - as you say - spread of the files on the spinning disk are just exacerbating a normal system routine.

Anyhow, thanks again for taking the time to help

Cheers

Chris

I suppose the only thing that still confuses me slightly is that everything will happily run smoothly - no glitches, no slowing - until lsof starts despite the dinosaur drives. But maybe the sheer size and - as you say - spread of the files on the spinning disk are just exacerbating a normal system routine.

How many undo steps in your Logic preferences?

The default is 100. I have it at 15 to reduce the memory footprint of the project.

another hint for chasing down problems - get comfortable with Terminal. Keep one open so you can do something like this

ps -auxwww >whyme.log

when things slow down. The 'ps' command will list all of the processes, and the commands at that point in time. The file 'whyme.log' can be perused to see if anything else is going on while Logic is being "pokey".

Just to say...

Delighted that I've found the culprit. Roland Cloud Manager sitting quietly on my top right menu bar initiating this "lsof" process and bringing everything to a standstill. I found out by using the View> All processes, hierarchically option in Activity Monitor. Showed that the Roland app was responsible. Turned it off and the issue has totally disappeared. Thanks for the help though chaps, much appreciated. Chris

Hmmm, that's not very nice behavior for a piece of software. Think I will be skipping the Roland Cloud things...

Glad you found the culprit.

ChrisNightingale - you total legend!! I’ve got a deadline and for some reason today (never happened before), the lsof process is killing my system. I have everything sample based on NVMe over TB and I keep getting glitches and CPU problems with hangs and freezes etc.

Spent ages researching and found nothing until your post.

Bloody Roland Cloud Manager!!

I haven’t tried it yet but I’m convinced this is what it will be...

Thanks in advance!!