2.4.3 Performance issues - session locks

2.4.3 Performance issues - session locks

by Susan Mangan -
Number of replies: 20

We just upgraded our prod server to 2.4.3+ (Build: 20130405)  and have had increadible performance issues due to problems with queries getting 'stuck'.  php errors we are getting consist mostly of session locks, Error writing to database Debug: Deadlock found when trying to get lock.  We've had to restart the DB twice to clear it up...we have a very robust DB server with gigs of cpu, memory, buffer, etc. there is no indication of a problem here.  Similarily, our front end VM is not reporting any problems with memory, space, etc. resources are all checking out.  I, personally am not a DB or apache expert but do administer Moodle and know enough to liaise with our DBA to try to resolve this issue.  I see there are other posts with this issue so I'll continue to investigate through others but in the meantime, if someone has some ideas for us the sooner the better - thanks so much...

PHP 5.3.3
Apache - Red Hat 2.2.15
MYSQL 5.5.25

 

 

Average of ratings: -
In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

Watching the mysql connection usage which is gradually increasing.  It looks like there are about 40 queries in the queue now and the system is slowing down again after our last restart....not completely unresponsive yet, but getting very slow.  Not sure what to do at this point - what could be causing these queries to queue up like this?

I don't know if this is relevant or helps but we have a lot of queries queued up with this statement:

SELECT f.id AS id, f.contenthash, f.pathnamehash, f.contextid, f.component, f.filearea, f.itemid, f.filepath, f.filename, f.userid, f.filesize, f.mimetype, f.status, f.source, f.author, f.license, f.timecreated, f.timemodified, f.sortorder, f.referencefileid, r.repositoryid AS repositoryid, r.reference AS reference, r.lastsync AS referencelastsync, r.lifetime AS referencelifetime
                  FROM mdl_files f
                  JOIN mdl_files_reference r ON f.referencefileid = r.id
                  JOIN mdl_repository_instances ri ON r.repositoryid = ri.id
                 WHERE r.referencehash = 'bdb1bc8e0f3766a2e531658d20c1b32688aab174'
                       AND (f.component <> 'user' OR f.filearea <> 'draft')

In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

another php error coming through continually is:  

PHP Warning:  unlink(/data/moodledata/filedir/6b/6c/6b6c7389ee49628e69f286e31fe0e764e10c3cc6): No such file or directory in /var/www/moodle/lib/filestorage/file_storage.php on line 1654

seems related to the query that is "stuck":

SELECT *
                  FROM mdl_files
                 WHERE component = 'user' AND filearea = 'draft' AND filepath = '/' AND filename = '.' AND timecreated < '1367257651'

In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Hi

I suspect that the repository database and the physical files do not match. I've seen that happened in a Windows server ( https://moodle.org/mod/forum/discuss.php?d=227403#p987842 ).

There were various posts in the "General problems" forum about ways of checking that. Search for posts by Ken Task.
In reply to Visvanath Ratnaweera

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

hmmm - interesting.  I don't understand how that could have occurred within an hour or two at the time of the upgrade ... but will check into it nonetheless!  Thanks smile

In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Ken Task -
Picture of Particularly helpful Moodlers

Is the DB engine Innodb or other? UTF8 and collation utf8_general_ci?

There are some command line scripts in /moodle/admin/cli/ that will set engine and character set/collation.

Recommend https://github.com/rackerhacker/MySQLTuner-perl

And running it more than once over a period of time.  It does change recommendations after a period of time.

Also, please see: https://dev.mysql.com/doc/refman/5.5/en/innodb-deadlocks.html

There's much to do with the new file system and the only way I've found to 'deal with it' in the new UI is to run cron ... a lot, at first.

This one, however, deserves investigation ...

/data/moodledata/filedir/6b/6c/6b6c7389ee49628e69f286e31fe0e764e10c3cc6

Look for a file named '6b6c7389ee49628e69f286e31fe0e764e10c3cc6' in /data/moodledata/filedir/6b/6c ... does it exist?

If it does, what are ownerships/permissions on it and all directories above it.

What is it?

file -b 6b6c7389ee49628e69f286e31fe0e764e10c3cc6 while in /data/moodledata/filedir/6b/6c will give you a hint/clue.

If the file is NOT there, the DB thinks it should be - there's a record for it.

New file system is an 'adventure' and until one gets things resolved one might have to do many searchs of the filedir (manually, from command line) to see if files exist.

'spirit of sharing', Ken

In reply to Ken Task

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

InnoDB ... not sure about the collation - it seems all of our DBAs are off today so I have to try to get in to see if I can figure that out.

Our DBA said that a tuner was not needed since the server was functioning properly.

I'll follow your advice and check out the file!  Thank you so much.

In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Ken Task -
Picture of Particularly helpful Moodlers

Am not a DBA, so far be it for me (a lowly Instructional Technologist) to disagree, however, I have observed first hand this much ... a MySQL server can be functioning just fine but it's NOT optimized.  Before I ever ran tuner for the first time, there were no errors, just sometimes slow (hmmmmm).  After running tuner and installing mtop (a MySQL top app), I've not seen any 'slow queries' (there are probably some still there, just haven't found them yet).  But performance is acceptable and I've not had a MySQL daemon crash/crater, either (lucky me, huh?).

Uhhhh ... so your apache server is on RedHat and the backend dedicated DB box is on Windows?  That's a strange mix and maybe why the DBA you asked concerning tuner (if you passed that along to them), choose to ignore.  Tuner is Perl.  Perl is not native to Windows.  Adds to the complexity of something that is relatively easy/simple on Linux ... but that's my take, of course.

As far as those slow queries ... the new file system is strange ... files that are not linked in any course are eventually moved to the 'trashdir' and when 'empty trash' kicks in via cron those files are removed not only physically from the trashdir but also any references in the DB that point to them.  Maybe when you had one of those crash episodes, files had been removed physically, but the DB never got updated or vice-versa. 

Moodle DB determines when files are moved to the trashdir by a timestamp field - like the timecreated < '1367257651' you see in one of your examples.

From the looks of that query (the 40 building up) looks like all the files they refer to in the DB may not be found in filedir.  The only way one can determine for sure is to x-reference them manually.

Here's one shown:

bdb1bc8e0f3766a2e531658d20c1b32688aab174

On your Apache server (which is Red Hat - thus Linux) as root user:

cd /data/moodledata/filedir/

ls -l bd/b1/bdb1bc8e0f3766a2e531658d20c1b32688aab174

is the file there?

If so there should be a corresponding entry in the DB:

select contenthash from mdl_files where contenthash="bdb1bc8e0f3766a2e531658d20c1b32688aab174";

The only way I know to correct that issue is manually checking for the existence of a file.  If not there, remove references in the DB for them.

Also have to ask this about the system since there  is a mix of platform ... is /data a mount point or is it a partition on the drive where the apache server resides?

As root user on the RedHat Apache Server:

cd /

ls -ld data

Will tell ya.

In an efficient way to check for the existence of all files contained in the DB, have you DBA, dump a query of mdl_files table for 'contenthash' into a text file.

Then, on the RedHat Linux server, upload that text file to /data/moodledata/

Using that contenthash.txt file one can write a simple script to read each line of the text file, and search ./filedir/*/* for it's existence.

Using the one example we have: bdb1bc8e0f3766a2e531658d20c1b32688aab174

from /data/moodledata/ issue this command:

find ./filedir/ -name bdb1bc8e0f3766a2e531658d20c1b32688aab174

That should show location of the file

Example:

[root@sos moodle23data]# find ./filedir/*/* -name a5b4ffa9e9a17113765a1153a5fb58b35b85f615
./filedir/a5/b4/a5b4ffa9e9a17113765a1153a5fb58b35b85f615

and to see what is is:

file -b 'locationoffileshownabove'

as per example:

./filedir/a5/b4/a5b4ffa9e9a17113765a1153a5fb58b35b85f615

And what type of file it is:

[root@sos moodle23data]# file -b ./filedir/a5/b4/a5b4ffa9e9a17113765a1153a5fb58b35b85f615
Zip archive data, at least v2.0 to extract

If you get that text file:

for f in $(cat contenthashdump.txt);

do

echo "Checking: "; echo "$f"

find ./filedir/*/* -name "$f"

file -b  ./filedir/*/*/"$f";

done

Obviously, if the find doesn't find the file -b won't work. ;)  And, the dump will contain references to '.' and some other strange stuff that won't be found.

Am sure your DBA could so something similar to this to get a fairly clean contenthashdump.txt file:

mysql -host XXXX -u root -p moodleDB -e 'select contenthash from `mdl_files` where (`mimetype` not like "docume
nt/unknown" and `filepath` not like "%/tinyicon/%" and `filepath` not like "%/thumb/%" and `filename` not like ".") INT
O OUTFILE "/data/moodledata/filedir/contenthashdump.txt"'

That would be issued from the RedHat Linux server (assuming it might have mysql installed even if using the Windows box).

Also, the query above should be on ONE line ... not wrapped as portrayed in this posting.

Run a little scirpt similar to above which checks for existence of backup files.  Out looks like:

Checking:
./filedir/cb/98/cb98dbe42fc442de33ebca56aadce7897246c70d
Zip archive data, at least v2.0 to extract

if the file is found

and if not:

Checking:
./filedir/6f/5f/6f5f10e4ba53abcae2bd59239582d724f4f3c910
ERROR: cannot open `./filedir/6f/5f/6f5f10e4ba53abcae2bd59239582d724f4f3c910' (No such file or directory)

'spirit of sharing', Ken

In reply to Ken Task

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

I see your point about the tuning however I am not in control of that area sad  I believe the reason our DB is on a seperate windows box is because of the internal expertise in the IT department.  We have an mssql dba trying his best to support the mysql system as well.
I'm not sure about mount point or partition.. I did the ls- ld data and it returned:  drwxr-xr-x 5 root root 4096 ...

I will try to look for and remove these missing file references to see if this helps with all the deadlocks and session locking.  Thank you so much for your detailed instructions smile

I guess the question remains, why are all these files missing since the upgrade?  Looking back to the php logs there are many errors with regard to missing files right after the upgrade and there are other errors in the logs that don't make a lot of sense to me.  However, there were no actual upgrade errors that came through during the time of the upgrade and no errors returned during testing to indicate that there was a problem.

 

 

In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Ken Task -
Picture of Particularly helpful Moodlers

The ls -ld data listed it so appears NOT to be a mount point and is physically on the Apache/RedHat server.

Ok, so the DBA has MS shingles.  Understandable one would think that way.  However, as one looks around internet and at some of the really big implementations of things, none seem to be running on Windows.  Case in point: NY Stock Exchange, Amazon, and let's not forget Google. Really see no advantage in running anything for Moodle on Windows. ;)

Ok ... off my soapbox now ...

'I guess the question remains, why are all these files missing since the upgrade?'

I really can't answer that ... don't think anyone could without performing forensics on both servers.  You did say the DB server crashed did you not?  Apache server *might* have been in a process of moving non-linked files to the trashdir when the crash of the DB box occurred.  That's like un-plugging the power cord to a server ... no server has enough time to re-cover anything and probably can't re-cover some things ... ever.  Apache server (ie, Moodle) has to get info from the DB server to know what to move, what to delete, etc..

Think focusing on 'clean up' is the first job - getting the filedir to match what's in the DB.  And, tweaking the DB as well.

That would make a very good 'health tool' for Moodle admins ... checking the 'health' of DB references to files with the physical contenthash file names found in filedir (orphaned files?).  And a comment, have never seen any system that didn't give the super admin control over it all.  But, such is Moodle 2's file system so sometimes one is forced to turn to the DB to resolve problems with it.  My 2 cent experience and opinion, of course! ;)

'spirit of sharing', Ken

In reply to Ken Task

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

No, no crash during the upgrade itself or afterward.  We did restart the db service when it became unresponsive after a few hours before we knew what was causing the system to be unresponsive.

i do have a lot of control and although I have a fairly solid knowledge around the db and server I'm by no means an expert DBA nor an apache/php expert so I often consult with the internal experts when I try to investigate these issues.  Once we get things on track again I'll definitely look into more optimization tools for myself smile

Back to the issue - I'm very confused here...I've been looking at this far too long mixed Here is an example of one of the queries that seems to be loading up in the queue (there's about 80 or so of them which is, I assume, the cause of all the deadlocks and session locks were are having):

SELECT f.id AS id, f.contenthash, f.pathnamehash, f.contextid, f.component, f.filearea, f.itemid, f.filepath, f.filename, f.userid, f.filesize, f.mimetype, f.status, f.source, f.author, f.license, f.timecreated, f.timemodified, f.sortorder, f.referencefileid, r.repositoryid AS repositoryid, r.reference AS reference, r.lastsync AS referencelastsync, r.lifetime AS referencelifetime
                  FROM mdl_files f
                  JOIN mdl_files_reference r ON f.referencefileid = r.id
                  JOIN mdl_repository_instances ri ON r.repositoryid = ri.id
                 WHERE r.referencehash = '8af209bc41d1f9221c1e6a92c4e06cbded77f4cb'
                       AND (f.component <> 'user' OR f.filearea <> 'draft')

I cannot find an instance in mdl_files where contenthash = 8af209bc41d1f9221c1e6a92c4e06cbded77f4cb nor in mdl_files_reference where referencehash = 8af209bc41d1f9221c1e6a92c4e06cbded77f4cb

nor is there a physical file in the data/moodledata/filedir/8a/f2/8af209bc41d1f9221c1e6a92c4e06cbded77f4cb

nor is there a physical file in the data/moodledata/trash/8a/f2/8af209bc41d1f9221c1e6a92c4e06cbded77f4cb

This is the case for many of these queued up queries ... how can I remove a reference in the db if it doesn't exist...

Then I found this... https://moodle.org/mod/forum/discuss.php?d=200201

Still kind of looking into it but it seems similar to our issue....

 

 

In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Ken Task -
Picture of Particularly helpful Moodlers

Did you run the cron job from the command line?  Please do so *AFTER* tweaking php.ini values.  The same ones referenced in the other discussion about a similar problem. 

max_execution_time = 3600 (or higher)

Tweaking php.ini values are system wide and do require the restart of apache service for apache to pick up the changes.

As root user: /sbin/service httpd restart

I'm almost willing to bet that the cron job is getting hung on a process related to files ... deletions, etc..

Also, if one had command line access to the DB box one could also restart the mysqld server - which, I think, would clear those queries qued up.

You might have to consult with someone else, but since the web server is Linux, consider installing something like Webmin.  It's perl based and gives one a web based interface into config of the server ... and it has a mysql tool which one could point to the backend DB box.

'spirit of sharing', Ken

 

In reply to Ken Task

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

Yes, I'm on development now and I've changed php values and restarted httpd.  I am re running cron now.  It does seem like that is what the issue is ...

I don't have command line access to the DB box sad  I have mentioned this though and will definitely have it set up for the future. 

restarting the db did clear the queries up - we did that on production a couple times however they just continued to build up over a period of time. 

... will keep testing this theory, thanks again for all your help - so very appreciated ... feel like we are grasping at straws sometimes...

In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Ken Task -
Picture of Particularly helpful Moodlers

Welcome.  Sounds like your close to resolving on the dev box.  Questions remain concerning the production DB server.  Might have to tweak the setting even higher if there is slow connectivity.

By chance are you also running any repository related to files ... dropbox, etc..

BTW, one should be able to install tuner on the Linux box and point it to the DB on the DB server.   Same goes for mtop.  That might disclose issues with the backend db server.

'spirit of sharing', Ken

In reply to Ken Task

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

I changed the php settings: max_execution_time=4200, memory_limit=2048 and max_input_time=600.

This seemed to help but after further investigation it looks like we have 47,000+ rows of data marked as 'draft' with the following criteria:

SELECT * FROM moodle.mdl_files where filearea='draft' and component='user' and filepath = '/' AND filename = '.' and timecreated < [4 days before now];

Yikes.  Not sure how that happened.  I've disabled the cron call for this particular clean up job on our production server until we can find a way to clean up these records more efficiently.  Maybe re-enabling this particular cron function at 3 am or something when the system is not in use?

Will definitely look into tuners for optimization, thanks again so much for your help.

In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Ken Task -
Picture of Particularly helpful Moodlers

According to this (dated 29 June 2008):

http://docs.moodle.org/dev/File_API_internals

During editing, files are stored in a draft files area. Then when the form is submitted they are moved into the real file area.

Uhhh, disabling the cron for the administration of files (since admin has no control over the new file system) is probably what caused the issue to begin with ... cron job not completing.  Think the cron jobs for files are among the last of the cron jobs to be run.

Don't know that others would agree, but ....

Rather than disable, strongly suggest scheduling the cron to run during NON-prime time for your site.  Have no idea what time that might be.  One could, however, avert more issues by scripting the cron job to run after the site is put into maintenance mode and at a time when most users are not on the system.  The last line of your script could take the site out of maintenance mode.  That script is cron'd.  Cannot do this in the Moodle UI.

Script to run via operating system cron on the Linux server (located in /usr/local/bin/ and owned by root user).  Adjust for your system.

cd /var/www/html/moodle24/admin/cli;
php maintenance.php --enable;
php cron.php;
php maintenance.php --disable;

If cron.php fails to complete, one just runs the last line to get the site back online for users.

The maintenance mode will allow admin level users to login but teachers and students will get notification the site is un-available and won't be uploading yet more files.

Would think that getting this cleaned up and functioning as it should is critical at this point.

Suggest also putting a password on the running of cron - the one available from the web - by any user - logged on or not. ;)

I've asked and you've not replied to this ... what is the connectivity between your Linux Apache web server and the backened Windows MySQL box?  You can test that with tuner on the Linux box - am imagining that one will see tuner make recommendations similar to php increasing time limits.  I truely do think connectivity between the two servers is a large part of the issue.  You are having to increase times in PHP in attempts to make up for it.

Is your Apache front end on a virtualized system?  Shudder the thought, but it's easy to increase things like memory and number of cores on such systems.  If there is enough room to hold the DB and MySQL, one could temporairly house the DB on the same server.  That should drastically reduced those times.   One could then setup better/faster types of connectivity if one really has to run the DB off Windows on the backend.

Since this is posted in hardware and performance ... wonder what others think about this combo ... Linux/Apache front end ... Windows MySQL backend ... and, if they have run such a setup, how did they get the fastest connectivity between the two servers?  Anyone?

'spirit of sharing', Ken

 

Average of ratings: Useful (1)
In reply to Ken Task

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

You are so helpful! :-)  I'm not sure about the connectivity between the 2 boxes, I haven't had time to explore the tuner on our dev box (but I plan to as soon as I can).  I'll send note to someone in INF to confirm...

I haven't disabled cron completely, only that one part (cleaning of draft files 4 days old) and only as a temporary solution so we could get our students and faculty functinal again (it's the first week of our summer semester and has been crazy).  My plan was to re-enable this cron process back during a non-peak/or during a maintenance period as you suggested - very soon.  Thank you AGAIN for your immensely helpful technical bits!!!

And yes we have apache VMs.  (long story - and not my idea)  First attempt a few years ago BAD - 2nd attempt last year ... better .... and improving).  When there are performance issues, the front end always seems to check out - lots of cpu, memory, etc.  As does the DB server.  There have been a lot of physical resources put into both. (yes I know we may have work to do on the fine tuning though smile 

I completely agree, this particular issue, I think, as you say, might have had to do with cron not running properly before the upgrade.  I'm going to go back to investigate when I have a minute to breath. 

We generally don't have a lot of performance issues - we've been running Moodle since the WEE early days (2005) and have gone through lots of trials and tribulations and different configurations!!  Unfortunately, we are a very small team (currently there are only 2 of us that really know the system inside and out) running a fairly large moodle shop with a neverending change in staff, administration and ongoing politics that changes the way we do things constantly *sigh*.  The 2 of us do top to bottom support and admin in consultation with our DBA and infrastructure team (our current DBA just recently got more on board with moodle stuff last year and our current infrastructure team doesn't know much about Moodle specifically).  Finding time and resources to do it all is very hard.  As most moodle admins can probably attest to!

YOU are an amazing help and source of information!  I hope I can give back the same way some day.  I tried years ago when things slowed down and enjoyed helping newbies - but workload is back up to 250% again and since we installed 2x last summer I've been slowly trying to build up my own knowldge-base around the system as a whole so I'm sort of depending more on others right now sad

<end rant> smile

In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Ken Task -
Picture of Particularly helpful Moodlers

One more technical thing for the server admins/network folks/DBA ... what is the connectivity between the Linux RedHat Apache/Moodle server and the DB box?  Would think something along the lines of fiber channel if you have a large implementation ... like a college/university or a K12 entity with thousands of students using.

Would still look at tweaks for the DB, but networking comes before application in such a setup.

Might consider turning off any heavy processing routines until the issue is resolved ... those would include automated backups and statistics, etc.

Also consider tweaking PHP variables on the Linux box upwards ... things like max_execution_time for scripts to run ... set those things for longer.  Looking at your phpinfo will show current settings.

Does your cron job complete?  Try it from the command line ... as root user cd /var/www/html/admin/cli/

then php cron.php

'spirit of sharing', Ken

In reply to Ken Task

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

I was just looking at that!  thank you ... our development box now has a copy of the prod DB and the moodledata so we are trying to recreate the problem.  I ran the cron scrip and it is definitely hung up on 'deleting old draft files'.  Interestingly, the apache/php errors coming out are:

[Mon May 06 16:54:44 2013] [error] [client 10.16.40.72] Directory index forbidden by Options directive: /var/www/moodle/lib/
[Mon May 06 16:54:55 2013] [error] [client 10.16.40.72] script '/var/www/moodle/lib/filestorage.php' not found or unable to stat
[Mon May 06 16:56:28 2013] [error] [client 10.16.40.72] File does not exist: /var/www/moodle/admin/cli/cron

the files definitely exist...

I checked permissions and our moodledata is set to 777 and moodle is 775 (recursively) ... our php limits seem a bit low compared to what is in that other post...

max_executive_time = 45max_input_time = 60

In reply to Susan Mangan

Re: 2.4.3 Performance issues - session locks

by Ken Task -
Picture of Particularly helpful Moodlers

These new errors are from the development box, right?

Is it also Linux RedHat? or some other Linux flavor.  Reason I ask, typically on a RedHat flavored linux, document root is /var/www/html/ and the moodle code directory goes in there.  That could be changed via httpd.conf file where document root is defined as /var/www/moodle.Is that how the dev box is configured?

also moodledata and the moodle folder need ownership by user apache/ group apache:

chown apache:apache /var/www/moodle -R

chown apache:apache /path/to/moodledata -R

Since you have a copy of the DB on that dev box, why not install tuner there and see what it says? ;)

*** And yes, tweak those php settings higher. ***

Restart apache /sbin/service httpd restart

Run the cron job again from the command line:

cd /var/www/moodle/admin/cli/

php cron.php

If it fails again ... ie, hangs on working with files ... it might have timed out again.   Check apache error log found in /var/log/httpd/error_log Again, tweak php settings upwards.  Restart apache service and TIA (try it again).

BTW, one could watch the apache error long in realtime ... in another terminal session (window) type: tail -f /var/log/httpd/error_log and hit enter.

And, in yet another terminal window, as root user run: top

That will show apache and mysql processes kicking in etc.. - one can also see when they stop appearing ... which could indicate a timeout has once again happened.

'spirit of sharing', Ken

In reply to Ken Task

Re: 2.4.3 Performance issues - session locks

by Susan Mangan -

I've checked and sure enough, some if these files that the DB is tripping up on do not exist. I wonder how this could have happened? I'm trying to recreate them to 'trick' the DB but I don't know how many there are, that might not be the most efficient way to go about this. Here is our db config:

character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server utf8
character_set_system utf8
character_sets_dir C:\Program Files\MySQL\MySQL Server 5.5\share\charsets\
collation_connection utf8_general_ci
collation_database utf8_general_ci
collation_server utf8_general_ci