freebsd 3G ramot lat a 4G-bol

FreeBSD-all

hello

kovetkezo a problemem.
adott egy dualxeonos intel szerver. 2g-rol felbovitettem 4g ram-ra.
a bios latja szepen a 4g ramot, de a dmesg-ben ez van:
real memory = 3221016576 (3071 MB)
avail memory = 3151155200 (3005 MB)
a rendszer:
freebsd 6.0 i386 smp kernellel.
google-t turtam, de semmit nem talaltam benne a pae kernel javaslaton kivul, az viszont rengeteg drivert nem kezel vagy untested, szoval nem merem megprobalni.
egyeb javaslata valakinek?

  • 1406 megtekintés

( andrej_ v | 2006. 06. 27., k – 17:41 )

AMD64-el próbáld, gondolom ez már újabb xeon. A normál PC-beli bios okosságok miatt 3-3,5-3700MB memót lát a cucc PAE nélkül. Ha 1,5 évesnél fiatalabb xeon, akkor jó eséllyel 64 bites ish.

igen mar ujabb xeon, freebsd amd64 megy rajta.
fentebb irtam hogy konkretan dmesg alapjan ennyit memoriat lat a kernel:
real memory = 3221016576 (3071 MB)
avail memory = 3151155200 (3005 MB)
amd64-et is hasznaltam de sajnos egyeb okokbol (a mysql eleg vicces random hibat generalt rajta, megoldatlan maradt, i386 alatt viszont tokeletesen mukodik) nem tudom hasznalni ezen a szerveren.
szoval lehetseges-e ravenni a freebsd 6.0-at hogy PAE nelkul i386-on lassa a 4G ramot es ne csak 3-at?

nekem olyan ufo hibat generalt hogy egy ideig nem merek amd64 kozelebe menni.
konkretan ha ugygondolta fogta magat es beragadt a mysql-be egy belso thread. semmifele utonmodon nem lehetett killelni csak magat a komplett mysql daemont, 1 megragadt thread megevett egy procit, ha a 4 db-ot elerte a szamuk (4procis gep) akkor borult az os.
vicces volt :)
i386-on a hiba nem all fennt.

Nekem ez FreeBSD 4.9-en volt, de az új vason és az új FreeBSD-n mexünt. :) A hibajelenség pontosan az volt, amit írsz, az egyik thread elkezdett 100% cpu-t enni és mysql restart kellett. Ez olyan néhány hetente vagy havonta jött elő (talán volt sűrűbb is, konkrét queryhez nem sikerült kötni, de gyanúsan vmi versenyhelyzet lehetett). A dologhoz hozzátartozik, hogy azóta 4.1-es MySQL-t használunk a 4.0 helyett.

hmm erdekes.
a vas relative uj, 5.4-es es 6.0-as bsd-vel teszteltem, konkret queryhez en se tudtam kotni.
csereltem gepet, mindket gepen probaltam 5.4-el es 6.0-val illetve mind a 4 variacion teszteltem 5.0.20-at illetve 4.1.18-at
mindenhol fennalt a hiba.
i386-al megszunt a hiba, es mivel egy online kameras oldal session adatbazisarol beszelunk igy ugye a mysql restart nem volt opcio, ez lett a fix megoldas.
ami meg vicces hogy se mysql forumban se mysql levlistan nem tudott senki semmit mondani.

( prygme | 2006. 06. 27., k – 19:48 )

Ez sajnos az elcseszett PC tervezés egyik, és reméljük utolsó kellemetlensége. Sajnos 3G ram felett minden PCI eszköz ~200Mb memóriát foglal el. Sajnos nemigen lehet ezzet mit kezdeni, a jövőben majd szépen kihalnak a PCI 'külső' és alaplapra integrált kártyák és átadják a helyüket a PCI Expressenek, ezzel a probléma megoldódik. A jelenben annyit lehet tenni, hogy kiszedsz minden felesleges PCI kártyát a gépből, és amit lehet PCI Express kártyákkal pótolsz. Ezen túl biosból letilassz minden olyan alaplapra integrált PCI eszközt amire nincs feltétlenül szükséged.
Esetleg tegyél át 1GB memóriát egy másik PCbe és használt csak 3GB rammal, ha nincs feltétlenül szükség 4GB memóriára. Ez egy gazdaságos megoldás.

( bra | 2006. 06. 27., k – 21:23 )

Milyen szerver/alaplap ez? Próbáltál már BIOS-t frissíteni benne?

(Most látom, hogy i386... Ettől függetlenül lehet, hogy tudsz nyerni vele egy kicsit.)

BIOS frissitest oszinten szolva celtalannak latom mert a bios latja szepen a 4G ramot.
csak a FreeBSD nem :)
egyebkent nemtudom a pontos tipusat, 2 unitos, dualtapos, 6 sata diskes, dualxeonos, dualethernetes ketyere.
alapvetoen van beloluk kurvasok es megbizhato taligaknak tartom oket.
eddig semmi gond nem volt veluk.