-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High CPU Load with IOS Clients using Active Sync #5045
Comments
How are you configuring EWS? SOGo (as part of mailcow) only supports EAS, and (to my knowledge) iOS doesn't support EWS for Active Sync either. |
What should I provide for further analysis? |
I think I might have the same issue. Logs also looks very similar. If I can provide something for analysis, let me know. |
Same here, I am experiencing the same behavior with about 12% CPU load per iOS device. Also happy to provide additional infos and logs on request. |
Same here. 150-200% CPU load on cloud server. Continuous dovecot (IMAP) logins. |
See #4857 |
Fixed for me after running |
I can't confirm that it is fixed in 2023-4b. |
Here is the same ... An IOS client causes in the log of Dovecot without end entries and an extremely high processor load with the service "dovecot /auth -w". After a restart of Sogo it is back to normal for 30-60 minutes. But after the time I have the same symptoms |
This issue is also discussed at mailcow community. |
I have the same problem with all iOS devices connected to SoGO, I have constantly around 30% CPU with 3 iOS devices and up to 1GB additional traffic per day because of this issue. I tried the workaround with copying one email into the Templates folder mentioned here, but it doesn't seem to change anything. https://bugs.sogo.nu/view.php?id=5626#c16323 |
It seems that I found the cause of my issue. It was a shared mailbox I had in my account, the folder How I found it:I enabled the Then I saw a lot of log messages like in this comment, inside the This seems like another SoGO EAS bug, if I have some time I will try to open an issue in their bug tracker. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
further activity. |
It's probably a SoGO bug and not really mailcow related. I didn't figure out how to report a bug to SoGO, maybe that would be a good next step. |
|
I have the same issue. Only from iOS devices connecting via ActiveSync. |
It's exactly the same issue for me, not the Template but the Shared folder. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
I'm still having this problem as well, showed up after iOS 16 came out over a year ago. I did get logs last time, it was similar to the error above but wasn't the Shared or Templates folder. I'll comment once it happens again with logs as I didnt save it. |
Just had it happen again, here's logs, essentially it just keeps spamming until I restart sogo container. I've redacted sensitive/personal information. You can also see the active-sync endpoint getting spammed in nginx logs. It may be the same error as mentioned here on sogo's bug tracker.
|
Interestingly, when I restart Nginx or sogo container it stops occurring for now. I am, however, running mailcow behind nginx with the configuration mentioned here. Does this have any leads? |
@Brend4n this looks like one broken message to me. did you try to delete this specific message? No idea though what is happening there. |
Well, I mean the error for the specific message disappears until the bug appears again with another message. That being said, it's clearly an issue somewhere if specific messages can somehow cause things to break. |
Yes, there is something wrong for sure, maybe more than one thing. But I think so far nobody did a writeup of the issues here and reported them to sogo. |
Well we did but no further response so far. |
Interesting, the last few times it has happened, restarting nginx didn't fix it however stopping nginx for a few seconds and then starting it again will "fix" it temporarily. I believe stopping nginx somehow causes it to terminate whatever loop it's stuck in. |
It will occur after some time again, I noticed that behavior too sadly that is not a fix. |
Reporting the same issue on my installation. Running 2024-01e. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
If someone wants to participate in our little conversation I would appreciate. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Nothing is staled, problem still persists. |
This is a SOGo problem, not mailcow. Please keep discussing at the SOGo issue you mentioned. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Not stale. This is still an issue for us. Does anyone know how to contribute to the discussion on the SOGo ticket? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Contribution guidelines
I've found a bug and checked that ...
Description
Logs:
Steps to reproduce:
Which branch are you using?
master
Operating System:
Ubuntu 22.04.1 LTS
Server/VM specifications:
RAM: 16GB, 8 Core
Is Apparmor, SELinux or similar active?
yes: Apparmor
Virtualization technology:
KVM
Docker version:
20.10.22
docker-compose version or docker compose version:
v2.6.0
mailcow version:
2023-02
Reverse proxy:
no
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check:
The text was updated successfully, but these errors were encountered: