And is running it on a debian container in proxmox.
Neither the CPU, the memory or the disk IO is showing a problem both CPU and RAM is topping at about 15% load…
But when I am saving a asset in farmOS gui it hangs up and I have to wait for about a minute before I can do anything more in farmOS, however if I create assets over api I have no problem at all using the python client or postman.
After trying some more and moving the storage from my fileserver to SSD it seams like some things got better but adding Land and plants are still very hard. Uploading images also dosen’t work at all everything else works even if some things are extremely slow it is updated when it responds again.
I realized that I hadn’t said that i have tried to reboot both the container and taking the docker down and up again.
I haven’t experienced this - I wonder if you can test it on another machine to see if there’s any difference? Maybe that would help isolate the issue.
What operating system are you running Docker on? I know that some environments have issues when mounting Docker volumes from the local filesystem. Macs in particular seem to have that issue, although maybe that’s been resolved. I don’t use Mac so I can’t say for sure.
Thank you, I have tried on different clients but only macs and android phones. I’m running docker on Debian 11 as a proxmox container so might try to set it up directly on the host or in a vm to see if I get the same issue there.
Trying it in a VM I saw an interesting thing when I installed it and that is that I had to go trough the setup twice first one time and then delete sites and db and start over and the second time it works and I had to do that both in the container and in the VM.
OK let’s separate the problems and think about them one at a time…
This is most likely a separate issue. File uploads require an additional setup step. Did you see this in the setup docs? Installing farmOS | farmOS
My hunch is still that the Docker volumes are to blame, only because that’s been reported in the past. But it may be unrelated. One way to test that is to comment out all the volumes in your docker compose file. This means that nothing will be persisted when you destroy the containers, but it should still let you install. If it works faster without volume mounts, then that will tell us where to continue investigating… If it’s still slow, then…
Does this happen on any other pages? Or just when you are saving an asset? Does it happen consistently? Or if you save the same asset again is it faster? Just trying to think about different scenarios… the more information the better…
I’m not sure I understand this. Can you elaborate a bit more? What do you mean by “I had to go through the setup twice”? And what do you mean by “and the second time it works”?
What I meant with that is that after i run docker-compose up -d I go through the installation guide setting db settings, installing modules and so on I get a page that says this site cant be loaded or something like that. But when I delete the volumes and let it recreate them the next time it works perfectly fine. This might very much have something to do with the volumes problem if that is the problem.
First try with deleting the volumes from the compose file failed but it might be that I didn’t recreate the containers so I will try again to see if that helps.
Yes that was correct, apparantly I missed that part of the installation instruction so that was an easy fix
Sadly it isn’t that consistent, It happens on saving and updating asset, plant_type and logs, but sometime I can save or updating without it going so slow but most of the time it is superslow. One thing is that it feels like it is happening more often with assets with a location but it also happens on plant_types and other thing in taxomony…
Hopefully it is the volumes so that we know where to troubleshoot.
Even after rebuilding the containers and deleting the folders for the volumes to make sure they wasn’t still there it is extremely slow to add a land asset, what i started with cause it feels like that always take a really long time.
And as I said before adding 20 plant_types through the API with the farmOS.py client worked just as it should.
I Just tried to install a new proxmox container that I installed farmos release directly on with nginx as webserver and it seems I have the same issue but will continue to test a bit more or otherwise I will try to install it in docker on my truenas server that the storage is on.
Edit: Installing it on truenas was harder than I thought because it seems they have disabled the possibility to run docker containers directly on truenas scale. But I will probably try to create a vm in truenas and run it there to test.
Thanks for reporting all your testing results @jorblad!
I wonder if you can see anything unusual in the Docker container logs (for either the www or db services)? Another place to check logs for Drupal specifically is via the farmOS UI at /admin/reports/dblog.
I haven’t found anything in the docker log for the www container other than a few “OPTIONS * HTTP/1.0” 200 126 “-” “Apache/2.4.56 (Debian) (internal dummy connection)”, for the db there was a few errors about config_import but when i uninstalled the import modules that I wasn’t using anyway those errors went away but not the problem.
The drupal log I didn’t know to look in earlier but there aren’t any logs from when the crash happens.
I have also tried to find other logs but none that says anything that I can relate to this.
Another thing I have seen is that in addition to clean API requests quickforms and asset link works great and as quick as would be expected.
If you open the Network tab of your browser’s developer tools, and submit the asset form, can you pinpoint which request is taking a long time to process? Are you able to take a screenshot of that and paste it here?
Ah you’re using Asset Link! Can you try uninstalling that and see if that makes any difference?
Edit: I don’t have any reason to believe Asset Link is the cause, but best to isolate the problem as much as possible. I would be curious if any of your tests above have been with just core farmOS and no add-on modules. That might help to narrow things down.
We could also get a bit more info with a slightly different screenshot of that failure…
@jorblad if you can recreate the scenario from the previous screenshot but click on the top network request line where is says “document” in the “type” column, it should show more information about the request headers.
It should look something like this; (though obviously mine was a successful request)