Trying my luck here before wrestling through the usual 'create new user', 'delete mcstate' and what more that support has as standard replies these days. This is not a new behaviour but have to ask since it's having a huge impact on one of our editors for a current production. The environment for this particular procution is macOS 10.12.6 (iirc), MC 8.10 and Nexis E4 2018.latest. Client is connected ofer 1Gbe.

Can someone explain to me why MediaComposer 8.x clogs down and gets slow when the attic for a projects has grown to something like 12GB and 4000+ files? It's not like the attic files are open in the running session. Or are there some sort of ancient database that it has to keep in memory at all times? Clearing attic and starting with an empty one gives significant speed improvments in EVERYTHING from UI navigation to editing. Can't really wrap my head around the reason of this slow down though.

Especially noticable when you have an editor that like to have 10+ bins open. The forced saves and auto saves can take forever when the attic is big. But for the love of God I can't see the reason to why. All it needs to to is to iterate up from the last saved version for each bin. And why is this faster in a small attic...?

And on the same theme. Why does it get so slow when having multiple bins open? Loads of free memory so that's not the rason. Nothing is really processing, just more tabs with open bins. What's the technical reason for that to slow MC down? 

PathDiag shows that we more or less max out the interface on read and write so it's not a network speed issue. 

Any good way to tweak the settings to make it bearable? 

Oh, and the second or third FOR THE LOVE OF GOD in this post... It's 2018, soon 2019... When will we get background save? Current situation is just mental and for someone like me that's really not an editor, how do you guys cope with this? 

Cheers and thanks

Small files take a longer time to save on a Nexis because it's optimized for large media files, not small bins and SearchData files like the ones used by PhraseFind or ScriptSync.

You can limit the number of versions stored in the Attic to keep the size under control.

Yes. Indeed. Not sure that answers the questions though. Why does a large attic folder slow down performance? It’s not like it will have all those files open nor in memory, or? So why would it impact everything in MediaComposer, from UI to file operations.

Saving an attic file to a clean and empty attic folder should in theory be as taxing to the system as saving it to a somewhat large attic folder. 

The only good news I have for you: You are not alone. This forum also has plenty of performance and bin saving related threads.

I personally see this issue at multiple sites. In very large attics (100G) it was always an issue and I do not consider it a big pain to just rename the attic folder, but the performance drop we currently see is so bad compared to the days of MC 5.5, MC 6 on even MC 8.4 or MC 8.6 that it really affects day to day productivity.

I agree 100% that the fault is it not the Nexis itself although Nexis client might be involved.

How exactly are you connected to the NEXIS?  Client is connected ofer 1Gbe - how?

Marianna

I avoided that on purpose in my original post. This since we see it on all our systems no matter how they're connected. So we see it on 1Gbe clients connected directly to Nexis Switch, 10Gbe clients connected to client switch and these clients that I was troubleshooting. This editor in particular doesn't have the same patience as our younger editors though and he works in a somewhat different way.

So, these clientes that this editor is working on are connected in a somewhat more delicate way with a few more switches and connection points...

Nexis => 10 Gbe fiber to Cisco Nexus n9k => 10 Gbe fiber to ISP CPE => 10 Gbe ether link to another facility across town and the CPE there => 10 Gbe fiber to Dell N3048P => 1Gbe to each client. 

So I avoided to write that since I assumed that this setup would be pointed at and shruged at as a non supported setup and that it would be given the blame for it. But as I said... We see "attic slowdowns" on local clients in the same facility as well, 1Gbe and 10 Gbe clients. We do have the speed and are well within supported latency on the "remote clients".

Cheers

In the case of local clients they're connected:

Nexis => 10 Gbe fiber => Cisco n9k => 1 Gbe copper => MacPro 5,1 builtin ethernet port

Nexis => 10 Gbe fiber => cisco n9k => 10 Gbe fiber => MacPro 5,1 Myricom 10 Gbe NIC

OK 2018.6 resolved the with Apple iMacPro 1,1 client systems using a 10Gb Thunderbolt adapter were unable to connect to an Avid NEXIS system.

So thats not it.   I also know that in 2018.6 on Mac Pro 5,1 using a 2 x 1Gb connection to the Avid NEXIS system, you might not receive expected data rates.

Are these Mac's ivy bridge or Westmere?

Marianna

Our main machines are MacPro5,1 mid 2010, Westmere. But we se this on all system regardless of OS and hardware. MacPro 2013, iMac's and the 5,1's. 

What I still don't understand is the technical reason to why a large attic would affect everything in mediacomposer, from GUI to editing. Does not make sense. At least not atm but I hope to be enlightened. 

Unrelated, but still somewhat related. We have a setup with a fiber between Stockholm and Oslo (Sweden <-> Norway). On our local machines in Stockholm I mounted the project workspace from Oslo and our "mirrored" local media workspace in Stockholm. We have a 7ms latency on this connection so it is NOT within spec. But we can open and work good enough for the assistants to use it. But what's super insteresting is that scrolling in the bin view is affected by the latency on this fiber. Also something that doesn't really make sense. I can only come to the conclusion that for each pixel movement of an item in the bin it does a refresh of the project? Why would a file list otherwise be affected? Not like this happens in finder or such, just media composer... Technical explanation for this...?

hbrock:

Small files take a longer time to save on a Nexis because it's optimized for large media files, not small bins and SearchData files like the ones used by PhraseFind or ScriptSync.

So shouldn't there be a way to designate a workspace (I think that's the name for Nexis partitions) to be media optimized or project optimized?

Short answer: no.

Longer answer: that would require being able to partition drives with shorter sectors optimized for smaller files. Unfortunately that would preclude the ability to resize workspaces on the fly as it would require differently formatted partitions.

hbrock:

Short answer: no.

Longer answer: that would require being able to partition drives with shorter sectors optimized for smaller files. Unfortunately that would preclude the ability to resize workspaces on the fly as it would require differently formatted partitions.

So, two servers then?  One with short sectors for the projects and one with long sectors for the media?  A fixed size project workspace might be a small price to pay for faster (decently accessible) bin access.   Could one server be configured to hold both keeping it in one rack?