Search Very Slow (3 minute response)

[crash1015 8]

Not sure if this helps, but recreating the libraries appears to have improved the situation, though it hasn't completely resolved the issue. I was previously seeing around 10–15 crashes per day, and that has dropped to roughly 1–4 crashes per day. The problem still exists, but it doesn't seem to occur as frequently now.

[Napsterbater 35]

It would be one thing if the search results were just slow and that was it. 

The fact that for us that are affected it completely locks up a server for up to multiple minutes, which is just ridiculous.

For those affected too, we cannot disable search. Otherwise that would be a simple workaround, instead if any of my users forget and click on search, they break the server for a couple of minutes for everybody.

[crash1015 8]

I disabled Global search in the settings for each library, that seems to have fixed it for now. Obviously searching doesn't work while that setting is turned off. But at least it prevents people on Apple TV/etc from searching. 

[Rumzzz 50]

Another month without a fix, or rollback even. I'm struggling to get even single word searches to pull results.

 

[bandit8623 244]

pretty crazy this bug hasnt been squashed yet.  i dont have the issue,  but i really feel for those who do.

[17732 23]

7 hours ago, Rumzzz said:

Another month without a fix, or rollback even. I'm struggling to get even single word searches to pull results.

 

I added two solid-state drives as read cache to the two mechanical hard drives of the Synology DS918. The speed of the EMBY has become very fast. When I didn't add the solid-state cache, it often freezes, and restarting the EMBY takes 20 minutes to restore normal use. Restarting EMBY now will restore normal operation in 3 minutes

[kingom 10]

1 hour ago, 17732 said:

I added two solid-state drives as read cache to the two mechanical hard drives of the Synology DS918. The speed of the EMBY has become very fast. When I didn't add the solid-state cache, it often freezes, and restarting the EMBY takes 20 minutes to restore normal use. Restarting EMBY now will restore normal operation in 3 minutes

how big is your library?
mine only takes seconds to start up.

[17732 23]

25 minutes ago, kingom said:

how big is your library?
mine only takes seconds to start up.

Movie: 6145
Program: 2450 episodes, totaling 95566 episodes
Music: 124000

[kingom 10]

expect for music i have about the same amount.

but i use nvme instead of ssd, but shouldn't make that kind of a difference.

[Napsterbater 35]

4 hours ago, 17732 said:

I added two solid-state drives as read cache to the two mechanical hard drives of the Synology DS918. The speed of the EMBY has become very fast. When I didn't add the solid-state cache, it often freezes, and restarting the EMBY takes 20 minutes to restore normal use. Restarting EMBY now will restore normal operation in 3 minutes

This thread is about only search causing the lockup issue. 

Nothing about starting up. Nothing about any other aspects of Emby only search. 

You're derailing the thread

[17732 23]

11 hours ago, Napsterbater said:

This thread is about only search causing the lockup issue. 

Nothing about starting up. Nothing about any other aspects of Emby only search. 

You're derailing the thread

Because searching on my Apple TV's Emby used to be really slow too, but now it's faster. I'm wondering if it has something to do with this solid-state cache

[HandsGroober 6]

I thought I had solved this issue by giving Emby server more vCPUs. While it appeared to help briefly, I'm now back to having short word searches locking up the server entirely. For example, searching 'big' will lock up the server. I think the issue compounds itself with users attempting to search repeatedly while not letting their initial search complete. I've disabled global search in all my libraries.

It's a very frustrating issue. I hope there is a solution soon.

Edited 23 hours ago by HandsGroober

[bandit8623 244]

11 minutes ago, HandsGroober said:

I thought I had solved this issue by giving Emby server more vCPUs. While it appeared to help briefly, I'm now back to having short word searches locking up the server entirely. For example, searching 'big' will lock up the server. I think the issue compounds itself with users attempting to search repeatedly while not letting their initial search complete. I've disabled global search in all my libraries.

It's a very frustrating issue. I hope there is a solution soon.

what is the vcore speeds?  can you try to have server keep cpu at max freq and see if any changes?  emby doesnt use a lot of cores its more reliant on cpu freq

Edited 23 hours ago by bandit8623

[Rumzzz 50]

I recall the stacked search issue being addressed with an update. If I make repeated searches, only the last search will continue to run. Regardless, that last running search will still lock things up.

I also set the Emby process affinity exclusively to the P cores on my 13600k. Did nothing for the search, but made the rest of the UI a bit more snappy.

Edited 23 hours ago by Rumzzz

[Napsterbater 35]

4 hours ago, bandit8623 said:

what is the vcore speeds?  can you try to have server keep cpu at max freq and see if any changes?  emby doesnt use a lot of cores its more reliant on cpu freq

Bare metal Windows with an AMD Ryzen 9 3950X, This happens, it pegs out a single core/thread, seemingly no* amount of CPU frequency is going to help.

 

Edit: typo

Edited 18 hours ago by Napsterbater

[bandit8623 244]

36 minutes ago, Napsterbater said:

Bare metal Windows with an AMD Ryzen 9 3950X, This happens, it pegs out a single core/thread, seemingly numb amount of CPU frequency is going to help.

Not sure why I'm getting down voted.  I'm guessing most people run their systems on a powersave. Which keeps clocks low.  If it is single core having high frequency on that core will help.  Even more important likely for systems running software raid..  

Edited 20 hours ago by bandit8623

[bandit8623 244]

3 hours ago, Napsterbater said:

Bare metal Windows with an AMD Ryzen 9 3950X, This happens, it pegs out a single core/thread, seemingly no* amount of CPU frequency is going to help.

 

Edit: typo

if its only pegging 1 core there are more issues going on.  emby should use more than one.  and yes core speed does matter.   maybe since emby is only using 1 core this is the problem.  

[Napsterbater 35]

3 hours ago, bandit8623 said:

if its only pegging 1 core there are more issues going on.  emby should use more than one.  and yes core speed does matter.   maybe since emby is only using 1 core this is the problem.  

That's part of the whole problem about this particular bug. This isn't related to just Windows, this isn't related to virtual machines.

When this bug is triggered, Emby maxes out a single process thread and thus a single core, with the exception of this particular bug and simply performing a search and be correctly, utilizes all available CPU power and threads and cores for all other purposes.

There are zero other performance issues from Emby In any other aspect of Emby, but if you attempt to search immediately you get a maxed single thread, and the rest of Emby for any user on any client or web interface Is unresponsive.

And a full power AMD Ryzen 9 3950X running on bare metal windows experiences this, along with other users on different OSs and different hardware, some on bare metal some on virtual.

So no, the processor, virtual or not is not the problem, the clock speed is not the problem.

[Rumzzz 50]

While I agree that the CPU/core utilization of Emby needs fixing (specifically for the search), I want to emphasize that it's a distinctly different issue and probably merits its own thread.

This thread is specifically for the recent change of the searching query logic.

Before the query logic update, the core/thread utilization issue still persisted, but only lasted for 10 seconds before search results were returned. 

I'm not sure how much the search would improve with a properly implemented multi-threaded search, but the main point of this discussion is that it's the query logic that needs fixing.

Edited 13 hours ago by Rumzzz

[bandit8623 244]

11 hours ago, Rumzzz said:

While I agree that the CPU/core utilization of Emby needs fixing (specifically for the search), I want to emphasize that it's a distinctly different issue and probably merits its own thread.

This thread is specifically for the recent change of the searching query logic.

Before the query logic update, the core/thread utilization issue still persisted, but only lasted for 10 seconds before search results were returned. 

I'm not sure how much the search would improve with a properly implemented multi-threaded search, but the main point of this discussion is that it's the query logic that needs fixing.

while i totaly agree on many points.  on my server when a search happens i never see even a single core get maxed.   and i dont have the freeze or stalls.  

so just trying to get more info out there.  Hopefully they can figure it out.