Weird issue when saving in farmOS

Hosting farmOS
1

Hi I have installed farmOS with this docker-compose file.

version: '3'
services:
  db:
    image: postgres:12
    volumes:
      - './db:/var/lib/postgresql/data'
    ports:
      - '5432:5432'
    environment:
      POSTGRES_USER: farm
      POSTGRES_PASSWORD: farm
      POSTGRES_DB: farm
    restart: always

  www:
    depends_on:
      - db
    image: farmos/farmos:2.1.1
    volumes:
      - './sites:/opt/drupal/web/sites'
    ports:
      - '80:80'
    restart: always

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.

Edit:
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.

Edit 2:
I realized that I hadnā€™t said that i have tried to reboot both the container and taking the docker down and up again.

1 Like
2

Hi @jorblad - welcome to the farmOS forum! :smile:

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.

Edit: See Docker mac symfony 3 very slow - Stack Overflow

3

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.

1 Like
4

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.

5

Tried in the VM now and I have the same problem there so either its something with my host or with my docker-compose file but I cant see what it could be on thatā€¦

6

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ā€¦ :person_shrugging:

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ā€?

7

Sounds reasonable, I will look at that when Iā€™m at my computer again :slightly_smiling_face:

8

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 :slight_smile:

9

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.

10

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.

11

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.

12

@mstenta I should also say that other servers that run on the same system donā€™t have simliar problems but I wonā€™t say that it isnā€™t something with my system somehow.

Edit:
And now it seems to start to be more consistent that every second save it has problem, both on the one running in docker and the one that isnā€™t.

13

Same issue on the truenas server in a VM so for now I will just live with it and if I have lots of assets to add I guess I will try to do them with the api instead.

14

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.

15

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.

16

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?

17

Took some tries because first it submitted directly and then I missed to start the recording in the developer tools. But I got this:

SkaĢˆrmavbild 2023-06-08 kl. 16.15.46
SkaĢˆrmavbild 2023-06-08 kl. 16.15.461022Ɨ1707 103 KB

I also checked the docker logs and in the www container i got [08/Jun/2023:14:10:20 +0000] ā€œPOST /asset/add/land HTTP/1.1ā€ 303 842 ā€¦ but in the db log I got nothing.

18

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.

19

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)

image
image1336Ɨ1434 204 KB

1 Like
20

The one I tested on a truenas vm was with only the core modules that I could choose under the installation.
I will add more information from dev tools tomorrow.

2 Likes