MySQL on MudOS/FluffOS

[melkor]

I can't see any increased memory usage on my dev server. Currently using FluffOS 2.13+MySQL with TMI-2.

[shadyman]

Using this significantly increased memory usage on my testserver (about 50MB more at startup).
Does anyone else see anything like that?

You mean in regards to the driver?

[wodan]

memory usage reported in 'top' for the driver when using a recent Mysql instead of the old one that's compatible with current FluffOS releases.

[melkor]

I'm currently using FluffOS 2.13+MySQL with TMI-2 mudlib, on a top of Debian GNU/Linux with kernel 2.6.24.5 and MySQL version 5.0.51a-16-log (Debian).
The machine is with 512Mb RAM and on "top" the driver shows a usage of 0.5% memory at startup and when i log in.

[shadyman]

"top | grep driver" shows my driver running at between 0.3% - 0.7% CPU and 3% memory, 18 day uptime

Fluff: 2.13
MySQL: 5.0.51a-3ubuntu5.1
Kernel: 2.6.24-19-generic
Processor: 600mhz
Memory: 312.97 MB

[shadyman]

Hi all! I've released my SQL daemon code for the DS lib here, if anyone wants to port it to his or her lib

[Yarp]

I've added in MySQL support into my copy of FluffOS and it works fine - I've already moved over all of the player files and it's incredibly easier to work with now than it was before with traditional files.

Any reason why this isn't in FluffOS yet?  This topic is a number of months old and there have been a number of new releases in the interim.

[wodan]

yes, the reason is my test mud uses way more memory when using the new mysql version, not putting this in until I know why!

[shadyman]

Maybe something else is causing the load? Try modding a fresh driver? 

[shadyman]

Hmm, I'm having a weird issue, I'd like to know if anyone else is.

Try a query for "SELECT COUNT(42)" and see what the result is? All I'm getting are 0's for count()s.

Is it just me?

[shadyman]

Hmm, I'm having a weird issue, I'd like to know if anyone else is.

Try a query for "SELECT COUNT(42)" and see what the result is? All I'm getting are 0's for count()s.

Is it just me?

For example, given the following code..:

Code: [Select]

    string* ret = ({});
    mixed rows;
    int i, handle;
    string query = "SELECT 'woo', 42, 'foo', COUNT(4)";

handle = db_connect("127.0.0.1", "db", "user");
rows = db_exec(handle, query);
for(i=0; i<=rows; i++) {
    ret += ({ db_fetch(handle, i) });
}
db_close(handle);
return ret;

Returns: ({ ({ "woo", "42", "foo", "COUNT(4)" }), ({ "woo", UNDEFINED, "foo", UNDEFINED }) })

So, as you can see,  the number and the count() both went in properly, but don't come out. Of course, this same query through MySQL itself (ala PhpMyAdmin) returns as expected, with "woo", 42, "foo", 4

[shadyman]

I changed the FIELD_TYPE part of /packages/db.c to read:

Code: [Select]

} else {
    switch (field->type) {
case FIELD_TYPE_BIT:
case FIELD_TYPE_TINY:
case FIELD_TYPE_SHORT:
case FIELD_TYPE_DECIMAL:
case FIELD_TYPE_NEWDECIMAL:
case FIELD_TYPE_LONG:
case FIELD_TYPE_INT24:
    v->item[i].type = T_NUMBER;
    v->item[i].u.number = atoi(target_row[i]);
    break;

case FIELD_TYPE_FLOAT:
case FIELD_TYPE_DOUBLE:
    v->item[i].type = T_REAL;
    v->item[i].u.real = atof(target_row[i]);
    break;

case FIELD_TYPE_TINY_BLOB:
case FIELD_TYPE_MEDIUM_BLOB:
case FIELD_TYPE_LONG_BLOB:
case FIELD_TYPE_LONGLONG:
case FIELD_TYPE_BLOB:
case FIELD_TYPE_STRING:
case FIELD_TYPE_VAR_STRING:
case FIELD_TYPE_TIMESTAMP:
case FIELD_TYPE_DATE:
case FIELD_TYPE_TIME:
case FIELD_TYPE_NEWDATE:
case FIELD_TYPE_DATETIME:
case FIELD_TYPE_YEAR:
case FIELD_TYPE_ENUM:
case FIELD_TYPE_SET:
case FIELD_TYPE_GEOMETRY:
                    if (field->flags & BINARY_FLAG) {
#ifndef NO_BUFFER_TYPE
                       v->item[i].type = T_BUFFER;
                       v->item[i].u.buf = allocate_buffer(field->max_length);
                       write_buffer(v->item[i].u.buf, 0, target_row[i], field->max_length);
#else
                        v->item[i] = const0u;
#endif
                    } else {
        v->item[i].type = T_STRING;
        if (target_row[i]) {
    v->item[i].subtype = STRING_MALLOC;
    v->item[i].u.string = string_copy(target_row[i], "MySQL_fetch");
        } else {
    v->item[i].subtype = STRING_CONSTANT;
    v->item[i].u.string = "";
        }
                    }
    break;

case FIELD_TYPE_NULL:
default:
    v->item[i] = const0u;
    break;
    }
}
    }
And now "SELECT 'woo', 42, 'foo', COUNT(4)" returns "({ ({ "woo", "42", "foo", "COUNT(4)" }), ({ "woo", UNKNOWN, "foo", UNKNOWN }) })"

So I think i'm getting closer. My guess is that at some point in MySQL development, they added new FIELD_TYPES, and the /packages/db.c hasn't been updated to reflect that.

So this begs the question.. What part of this code returns UNKNOWN as opposed to UNDEFINED in the stock version?

[shadyman]

It seems to be something to do with int.

when casted as both signed and unsigned ints, they return as UNKNOWN
({ ({ "woo", "cast(42 as unsigned int)", "foo", "cast(COUNT(4) as signed int)" }), ({ "woo", UNKNOWN, "foo", UNKNOWN }) })

A workaround is to cast as char, which returns it as a string.
({ ({ "woo", "cast(42 as char)", "foo", "cast(COUNT(4) as char)" }), ({ "woo", "42", "foo", "1" }) })

[wodan]

someone on slashdot claimed that anything linking with the mysqlclient lib needs to be GPL or you need the commercial license, and looking at the mysql web pages, I fear they may be right.

Does anyone know if that's always been the case? I don't see a reason to remove support if older versions allow it, but if it was never allowed, I'll probably have to.

[cratylus]

someone on slashdot claimed that anything linking with the mysqlclient lib needs to be GPL or you need the commercial license, and looking at the mysql web pages, I fear they may be right.

Does anyone know if that's always been the case? I don't see a reason to remove support if older versions allow it, but if it was never allowed, I'll probably have to.

I'm not an expert, so forgive me if my question is dumb-ish.

However, it was my understanding that this gpl linkage is a problem only
if distributing compiled code. For example, when I distributed (without knowing
it was possibly a problem) a Cygwin compiled MudOS executable, some
folks called foul on it. But just having "Cygwin support" in the source is
hardly violatory...right? If FluffOS links with some other gpl lib at compile
time, that's not your problem if you're not distributing the resulting exe...

Am I mistaken on this?

-Crat