Currently the server is 8 days uptime.
workload average ±9
workload average max: ±14
checking time = 900s
clients = 17000
Storage nodes = 110
Plugins enabled = Location
@fry_p Yeah I read it, but my first hit is to keep it more simplest as posible, I think that before to start to implement that it’s bette to do lesser works, there are a few months than I’m thinking that myISAM is not an optimal engine for this, almost for me, and I’m alone as FOG Sysadmin and need to keep my workload under control, I have not much experience with clusters and load balancing, and it’s no so good.
When I can I share documentation about our installation and customizations.
First let me say that FOG isn’t designed for this large of an installation. But I’m sure there are things we can do to optimized the installation. The first step is to get the database running well. Then we can look into other tweaks to help productivity.
Yes I know, but it’s a good project that fits on our needs.
My database analisys reveals than there are too many table locks that fall in poor performance. With this test, changing myISAM by InnoDB change the table locks by row locks, first problem seems solved, and currently have ,on the first moment, a workload average 7 (200 points lesser) with client checkins about 45min 1hour. now we can add cache and memory temporary tables, that can help to get the best database performance.
The change has been do it, now we are on “Test mode” and it feels like a great hint, all the help to increase performance on the installation are wellcome, and feel free to request me information, im glad to help.
By the other way, now you can get information about the convenience about change the database engine to get more performance, I’ll report all information than you request to me and I can.
The change than i made was the ALTER TABLES, no php code was touched.
Yes i have the database virtual server (mariadb 10.4) and fog web virtual server are different virtual machines.
The Virtual Sysadmin told me than the database server is stored on a mechanical sas.
On myISAM i have implemented all the recommendations, now i have innodb on basic configuration, I’ll do optimizations next week with a few days working.
I use FOG client, with a checkin time about 15min as test, currently workload average is about 15-17, but im still doing verifications.
By the moment this seems to work with out problems.
I do this changes because i detect a lot of table locks, that make a poor performance.
Hi to all,
I’ve a FOG System with 1 Master, 1 database out of server, 110 Storage Nodes on different towns and 17000 computer clients all with a variety of connections from adsl 2MB to 1GB FTTH.
I’ve been experiencing a big bottleneck on MySQL myISAM database with 200 on workload average and 3.70GB RAM.
I’ve take a decision i migrate the database to InnoDB to test on production, by the moment the work average are nearly to 6 and the memory on 3.50GB more or less.
I’ll give you notices on the next friday…, if you have more suggestions I’ll be pleased to study and test it.
By the moment it’s working by 2h 30min
@EduardoTSeoane I’d be very interested to hear if this quick fix helped to ease the DB load. We might consider make this value configurable through the web UI then.
Good Idea. When I get some tests on production I’ll post it here.
@Sebastian-Roth yeah, I don’t want te get rid the satus reporting, maybe to do it on another way that don’t use the database, I know that my System maybe is oversized but I want to help to get better performance to all.
I’m trying the solution on production, when i have some contrasted information I put a quote on this solution.
Have you try to execute the file manually?
Have you compared the size?
Maybe the download is not correct.
Would you mind trying on working-1.6? (Preferabbly the same database but on a test instance?) to see if performance is improved at all?
Ok, I’m ready to start the test, plz explain me how do you want the, bugs/problems report?
Try to verify than the snapin is replicated on the StorageNode.
I have that problem on my 1.5.6 and my solution was the snapin replication.
@EduardoTSeoane Ok, seems like I got a bit confused about the custom install path. Now I got it. Opened an issue on github for this so we won’t loose it: https://github.com/FOGProject/fog-client/issues/117
Hehe, that has name, is too much work…, I was thinking that it was a problem with our Windows Customizations, I had no time to investigate it.
@tomhtil Thinking about this a bit more I can only suggest to copy
token.datfrom Windows to Linux and back as a quick solution. I opened an issue on github for this so we won’t forget about it. I see it as a major change we’d need to make in the client and it’s not something we can do quickly.
On my last update the client break to malfunction on a lot of freezed computers that have the client installed on non default path, a little problem with the updaterhelper.
Can you give us some more details on this? I have to admit that I have not looked into the updatehelper code yet. Does it use default install path even if you had it installed in a different location?
Yes, I can… And Yes, I think so on my system.
We have a set of computers freezed, Because We don’t want to add another Freezer exception more, we install the fog client in D:\ Volume that we have unfreezed.
When i update my server from 1.4.2 (client 0.11.12) to 1.5.6 (client 0.11.16). We don’t prevent the computers to update the client, then the update uninstall the old client and try to install the new version, on next reboot the fog client was not there, my conclusion was that it was installed on freezed partition. The result all freezed computers with that client installation path goes down.
But I was thinking about that was a incident with my specific installation and custom configurations and system customizations, so I was thinking that it was not a FOGService problem, but I like to Advertise about take care with own customizations.
If you need more details…
Commenting the code into the function getPrimaryGroup($groupID) // line 367
The WebUI has reasonable performance.
Then i think that the problem is that the nested loop in fastmerge function on line 2397 of fogbase.class.php, “is not so fast hehe”, maybe it helps.
A lot of thanks for your efforts in advance.
Maybe this night i can configure de working-1.6 personal test server with my production database.