@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.

@george1421 Yeah, this is my hint. I’ll do the documentation, but I need time.

At this moment I’m having a workload of 7 with 17000 clients at 15min of checkin time.
Everything seems to work correctly.

Next friday I’ll do another report.

First at all, maybe this is not the correct thread, this
@george1421 said in Bottleneck on DATABASE:

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.

@Sebastian-Roth On production 1.5.7, i’ve been delayed on the working-1-6 tests

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

@Sebastian-Roth said in Database Stress when cloning on Big Environments:

@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.

@Sebastian-Roth ok im out ungió Next week. I test It Next week

@Greg-Plamondon
Have you try to execute the file manually?
Have you compared the size?
Maybe the download is not correct.

@Tom-Elliott @Sebastian-Roth
First problem with my data base.
Login two slow, I need to increase ProxyTimeout and Timeout get a successfull login

@Sebastian-Roth @Tom-Elliott said in Common WebUI pages takes minutes to load.:

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.

@Sebastian-Roth said in FOG client with dual boot image:

@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.

@Sebastian-Roth No, the installer is the msi version supplied by installation, the upgrade was from 0.11.12 to 0.11.16 and the server from 1.4.2 to 1.5.6

@Sebastian-Roth said in FOG client with dual boot image:

@tomhtil Thinking about this a bit more I can only suggest to copy token.dat from 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.

@EduardoTSeoane said in FOG client with dual boot image:

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…

@Tom-Elliott @Sebastian-Roth
Typo corrected and don’t solve the problem, i dive a bit more on the code, and now i’m on
/var/www/html/fog/lib/fog/snapin.class.php

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.

@Tom-Elliott @Sebastian-Roth ok i try it tomorrow and tell you if it helps.

@Sebastian-Roth 1.5.6 officially, and on my development/testing machine 1.5.7

yes i can try it, are there any database change? from 1.5.6? maybe i can do a realistic test with the same stressed database.

A bit of info more:

The problem is located on snapin.class.php function getPrimaryGroup($groupID)

Maybe i cant dive a bit more on the code.