I agree with everything Remus said and I started writing a long comment and realized this may be an additional answer.
You never indicated that this was causing a problem, just that you happened to catch it. That said if you are seeing waits on Log_Manager latches - it is a good indication that you are potentially not getting the best performance out of your transaction log. This could be due to several factors that you should look into:
1.) As Remus rightly pointed out - look at your log file. Is it constantly growing? Why? Are you shrinking it every night? Is it improperly sized? When this wait happens it is typically because you are growing the log file either because you aren't reusing it or you haven't sized it. These procs could be victims or aggressors (or both). Go to the links Remus suggested and check out this DBA.SE answer where I talk about various reasons why a log file can grow.
2.) Also for the log - if it is not properly sized that could cause some stress. Your log file should be sized right for your environment. The answer linked above explains that and links to some external posts from others that go into more detail there if you suspect that is the cause.
3.) Log Drive performance - while this isn't the primary cause of a log file having to grow, it could definitely cause a log growth to go on longer and could cause a log_manager latch to hang around longer. I would suggest that you look at where your log files are. Log fles are critical to your performance and success with SQL Server. SQL uses a write-ahead log methodology to maintain transactional consistency - If it isn't hardened to the log the transaction cannot be complete. Also, as Remus pointed out, the log file can't grow with instant file initialization so the growths require the operating system to zero out the files. If you are not setup for optimal log file performance you can suffer in many ways, this is potentially one of them (at least an exacerbation to the problem). Some guidelines to help:
- Generally speaking you want separate storage from your data files - there are caveats here based on what type of SAN you are on and the drive speed, etc. - but in general you want to keep your log files isolated for performance and recovery reasons.
- You want your fastest IO to be reserved for your log files (some can argue TempDB and I'll even join them depending on the environment, but log writes need to be fast, keep that in mind with your performance)
- Again this will differ depending on your storage provider but Log Files don't typically love RAID 5 - Mirrors or Mirroring and Striping tend to work out better here.