3doubled

Members
  • Posts

    56
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

3doubled's Achievements

Rookie

Rookie (2/14)

5

Reputation

  1. I'm going to give this thread a nudge. I'm also looking at upgrading my Unraid server from an ancient i7 920. I'd really like to ensure Plex hardware transcoding is working well on the upgrade. I had my eye on Intel 11th gen as I've heard 12th gen is still a mess in Linux. Is 11th gen working well? ucliker, you said it "wasn't unstable", which didn't sound like a ringing endorsement. 4k to 1080p working well? HDR tone mapping? Otherwise, I'm assuming the CPU side of 11th gen should be fine, since it is just skylake ++++++ Thanks in advance.
  2. Try: sudo -u abc php /config/www/nextcloud/occ maintenance:mode --off EDIT - path was incorrect before, fixed it. You can also change the maintenance value variable in config.php located at /appdata/nextcloud/www/nextcloud/config/ and reboot the docker.
  3. The spikes during upload transfer seem to be related to mysql performance. This person did some testing and was able to improve transfer speeds, especially for small files. The issue is that the biggest improvement comes from a change that is inherently less safe, so this is not a great option. Here is a 2.5 GB file being uploaded: This is the default with innodb_flush_log_at_trx_commit = 1 This is with innodb_flush_log_at_trx_commit = 2 This is with innodb_flush_log_at_trx_commit = 5 No other innodb setting change suggested in forums has made a significant impact, but that one certainly helps. Small file performance seems a bit better, but it still isn't great. The problem is that it weakens power loss protection so many suggest against this type of change. I still have no idea what is bottle necking the upper limit of performance, but there is obviously a beyond nextcloud issue here, as its also reported with owncloud.
  4. I know this is an old thread, but I just wanted to add that excluding the \appdata folder in Dynamix Cache Directories and setting the max level depth to 8 greatly reduced the CPU spiking behavior for me.
  5. I know this is an old thread, but I just wanted to add that excluding the \appdata folder in Dynamix Cache Directories and setting the max level depth to 8 greatly reduced the CPU spiking behavior for me.
  6. Bingo, that was it. Thanks johnnie.black! Now that I know what is causing it I see there are other threads about this here: This thread in particular people recommend either disabling cache dirs or at least excluding shares with complex folder structures, such as \appdata. I'm going to give the latter a try first, but disabling it might not be a bad idea, I don't spin my disks down ever, so cache directors is probably not doing much anyway. [EDIT] Excluding \appdata seems to have done the trick. I also set the max folder depth to 8 instead of unlimited. The CPU utilization spikes are gone entirely.
  7. Hi, While trying to diagnose performance issues related to my NextCloud docker I came across a weird CPU utilization pattern. The image below was taken with all dockers stopped except Netdata: Every couple of seconds, one core is utilized 100%. How can I identify exactly what process is doing this? Unfortunately, Netdata just labels this process as "other". Thanks PS. Here is my post regarding my NextCloud performance issue, although I don't think it seems to be related to this weird CPU behavior. tower-syslog-20190410-0059.zip
  8. Thanks for the suggestion ufo56. I had actually tried implementing all of your suggestions a few days ago, but the Redis changes crashed NextCloud and caused an "Internal Error" message in the docker UI (I realized my mistake and noted it below). This time I went back and added your changes individually. All testing was done on an gigabit LAN either uploading to my nextcloud share, which writes to a SSD cache, or downloading to an SSD: The upload baseline is the following, I see peaks up to 200 - 260 mbps (~30 MB/s) during upload, but transfer is not very steady, so the overall speed isn't great. See the attached image network performance image below "Nextcloud Upload Before Changes.png". Pretty slow for SSD to SSD transfer over gbit connection. The download baseline is better, I see rather consistent transfer speeds of ~310 mbps (~38 MB/s). First I changed the proxy.conf file by adding or changing the following lines in \appdata\letsencrypt\nginx. I then restarted the LetsEncrypt and NextCloud dockers. After making this change, I saw no noticeable difference in file transfer speed and it had the same bursty behavior as illustrated in the image I referenced above. Next I implemented the php-fpm changes. I did this by adding the following lines to the end of the www2.conf file in /appdata/nextcloud/php, hopefully that was the correct place and manner to make the change. I then restarted the NextCloud docker. After making this change, I saw no noticeable difference in file transfer speed and it had the same bursty behavior as illustrated in the image I referenced above. Next I implemented the changes in php.ini. I did this by adding the following lines to the end of the php-local.ini file in /appdata/nextcloud/php, hopefully that was the correct place and manner to make the change. I then restarted the NextCloud docker. After making this change, I saw no noticeable difference in file transfer speed and it had the same bursty behavior as illustrated in the image I referenced above. Next I enabled the Redis cache. After installing RedisI made those changes in the config.php file in \appdata\nextcloud\www\nextcloud\config. A mistake I was making previously was that you must replace IP with your server IP. For some reason I thought it would automatically grab the IP. This error was causing the Internal Server Error issue I had earlier. I then restarted the NextCloud docker. With all of these changes in place, nothing has changed and I'm still seeing the bursty upload behavior. I am also noticing that the peak burst upload speeds fall off over time. After transferring a few GB, speeds have fallen by about 50%. See attached "Nextcloud Upload After Changes Steady State.png". If I pause, wait a couple seconds, and then resume, the transfer is restored to "full speed" again, see attached "Nextcloud Upload After Changes Pause and Restart.png". So there appears there may be two issues: My max download speed appears to be limited to ~310 mbps (~38 MB/s) My max upload speed is similarly limited, but it also bursty, with an average transfer speed between 100 and 150 mbps (~12 - 18 MB/s) Any additional thoughts would be greatly appreciated. Nextcloud Upload Before Changes.png Nextcloud Download After Changes.png Nextcloud Upload After Changes Steady State.png Nextcloud Upload After Changes Pause and Restart.png
  9. Hi all. I'm a new NextCloud user and I followed Spaceinvader One's great video tutorial (Thanks Spaceinvader One!). I managed to setup NextCloud and the reverse proxy OK (it's functional), but I'm seeing speeds between KB/s and low MB/s speeds when either uploading or downloading files to/from NextCloud on a gigabit local network. If I copy the same files using file explorer in Windows, I hit 80 - 90 MB/s when uploading to the Unraid server shares directly (no cache). When I Google around, I see people reporting NextCloud speeds in the 80 - 90 MB/s range, so it seems something is wrong. Here is what I've speculated is the problem: There could be a problem with my reverse proxy setup, such as: Slow HTTPS encryption bottle-necking performance??? My desktop is failing to make a direct LAN connection with NextCloud and is going to the internet to reach my server. Even if I try to connect to NextCloud directly using the IP address, it is always resolved to the duckdns address I setup. Database performance related NextCloud is recommending I install Redis - which I can't seem to configure properly without breaking the NextCloud Server (I get a Internal Server Error 500 message. I was having some file locking errors initially, but these seem to have gone away for now. Any help would be much appreciated. If it would help to see any configuration files, please let me know which.
  10. Thanks everyone for the help, especially aptalca, I found the backups and was able to restore to a previous date and the library is now updating. Thankfully Plex was automatically creating those backups. I'll checkout trakt.tv too. Cheers.
  11. Thanks. Is there no way to just fix the corruption? I don't have a backup stored. If not, then how could I cause Plex to rebuild the database? Should I just delete the appdata and start again like I did last time. That's an ok fix, but kind of annoying since I lose all of the watched/unwatched info, which is what I'm hoping to avoid. Thanks
  12. I hope everyone is having a great weekend. I'm having trouble with my Plex server docker where it refuses to update the library. I've added several files to the watched folders, but they are all ignored. This occured around the time that my cache disk filled up, and I think it might be connected, as this happened a few months back and the only way I could solve the problem was to rebuild the plex server. Thus far, I've tried the scan, optimize, clean, empty trash options in the Plex server GUI. I've tried refreshing metadata (no luck so far). I've deleted the docker image and installed a new one (25 GB this time, in case that helps). Also, I've noticed that playing a file through Plex, even on my local network, take about 10 - 20 sec to load. It used to be instantaneous. I'm not sure if this is connected with the new player or the issue with my server. Short of building the server from scratch again I'm out of ideas, I'm hoping there is a better solution. I've attached my log file. Please let me know if there is anything else I can share. Thanks! Plex Media Server Logs_2018-03-24_19-08-05.zip
  13. A quick update. I later booted the server and found 4 (!) disks missing. It turned out that all 4 disks were connected to my motherboard via SATA cables, while the drives connected via SAS to SATA cables from my supermicro card were not seemingly affected. I considered it was either a SATA controller or SATA cable issue. I tried replacing all of the SATA cables with older ones, all of the drives appeared again, no issues!!! It wasn't a single cable, it was ALL of my cables. I replaced all of my SATA cables about 6 months ago because I had one bad cable and thought I could probably get better quality cables than the ones you get for free with motherboards. I bought the cables from monoprice, having been impressed with their cable quality in the past. Well... that was a mistake! HOWEVER, I'm not out of the woods yet. I rebuilt parity successfully, with no errors. Next, I swapped out an new RMA disk for the initial disk that had failed (because I want to send the old disk back). This was also seemingly successful with no errors... BUT 4 minutes after the rebuild, the parity drive goes down with a billion read errors and turns up a failed disk in the array. Also, unbelievably, Unraid reported that the parity drive had 18 QUINTILLION writes [i feel like that deserves a Doctor Evil Muahahah]. Suspicious, I check a couple of videos I had on the replaced disk. Many of them fail to start playing... that's not normal. I mount the disk I replaced with SNAP and try the same files, they play fine. OK, so my parity drive was failing during the rebuild. So now I want to do two things. 1) Copy the contents of my OLD disk11 to the RMA drive. To do this without parity I understand I need to preclear the RMA drive, partition it with gdisk, mkreiserfs, mount both drives with SNAP, and then copy with something like midnight commander. I need to send the old disk11 back shortly, because my shipping window is rapidly disappearing. 2) What do I do about my 4TB disk? I've been trying to do a preclear run on it, to see if it comes out error free (probably not) However, despite starting the array with no parity disk installed, preclear refuses to recognize the 4TB disk as an unassigned disk (despite it showing up this way on the unraid main page) Edit - I've realized that I needed to upgrade the preclear script, I imagine that should solve the issues. I've attached a diagnostic report of my latest config. I have the diagnostic report for when the parity drive blew up, but it is too big to attach here. You can find it here: https://www.dropbox.com/s/o5hmfpns0fb3x7g/tower-diagnostics-20151025-0935.zip?dl=0 Thanks for the help tower-diagnostics-20151029-2058.zip
  14. It is a Corsair TX650W, which has been powering my server without trouble for years.
  15. So after a long SMART test of my parity drive, no new errors were found. Otherwise, little new to report, other than Disk11 throwing the same bunch of link reset errors when being accessed. I've attached the latest diagnostic report. So how can I recover my array? - I don't feel like I can successfully rebuild the parity drive. If I attempt this, Disk11 will probably continue to throw link reset errors until Unraid boots the drive out of the array and/or the parity drive becomes invalid again. - I can RMA Disk11, but without a valid parity, I can't rebuild Disk11. I seem to be stuck. Is there anyway to force Unraid to validate the parity drive and allow me to rebuild Disk11? tower-diagnostics-20151014-2111.zip