Onderwerp: Snelle CPU?

Hoi,

Heb toch even jullie advies nodig voor het volgende:

Een genealogie applicatie(ik denk gebaseerd op access) is super traag bij opvragen gegevens, dedupliceren van data etc...

1 - Ram wordt amper gebruikt
2 - I/O valt mee
3 - Hij is niet te gebruiken over meerdere cores!

Puntje 3 is denk ik het grootste probleem gezien de cpu staat te blazen op 100%, dedupliceren kan 8 uur duren!
De DB bestaat uit 88.000 namen.

Ja ik weet het, de keuze voor deze applicatie is fout geweest, dat weet de klant nu ook wel maar switchen kan niet omdat deze uitgebreider is dan anderen.
Er gaat dus data verloren / linken worden vernietigd bij overzetting.
Ook is er contact opgenomen met de maker, het ziet er niet naar uit dat meerdere cores ondersteund gaan worden en beweren dat 1.000.000 namen moet kunnen...

Een SSD is al getest en geeft maar 15% snelheidswinst, schiets ook niet op.
Eigenlijk zou het mooiste zijn dat meerdere cores gebruikt kunnen worden en dat de app dit als 1 core ziet. (dus een 9Ghz cpu )
Dit is overigens op een standalone windows machine.

Iemand een idee?

Waarom kan overzetten niet? Lijkt me erg raar.

Die 100% is dus wel alle cores of maar 1? Ik begrijp het niet helemaal.
Kan de scripting wel wat optimized worden ook al pakt ie dan nogsteeds maar 1 core?

Oorspronkelijk geplaatst door Ramon Fincken

Waarom kan overzetten niet? Lijkt me erg raar.

Die 100% is dus wel alle cores of maar 1? Ik begrijp het niet helemaal.
Kan de scripting wel wat optimized worden ook al pakt ie dan nogsteeds maar 1 core?

Het kan wel overgezet worden maar er blijven altijd "onbekende velden" over op het nieuwe platform.
En bij 88.000 entry's die elk weer nam, adres, links met.. etc.. hebben, kan je net zo goed 88.000 namen opnieuw invoeren zeg maar.....

1 core 100% rest doet niets, dat ding kan maar op 1 core werken.
Het is een app he, een .exe met dll's etc... was het maar simpeler...
Dat ding stamt uit het dos tijdperk en is zo steeds verder uitgebouwd zonder in te zien dat ze verkeerd gaan met de structuur en nu is het te laat zeg maar...

Apart, slaat ie dan ook zaken op in het register?

Valt dit niet te virtualiseren? Dus dat je 1 virtuele core maakt die in feite bestaat uit alle cores?

Dat van het register moet ik controleren, ik weet wel dat hij elke wijziging wegschrijft op de HD als "backup".
En dat virtualiseren en als 1 CPU zien, tja dat was mijn laatste redmiddel om uit te zoeken in hoeverre dat kan.
Mooiste zou zijn dat er een "app virtualisatie" was die alle cores kan aanspreken zonder dat de app zelf weet dat hij dat doet.

Verder, het is wel een klant van me maar dit is iets prive van hem.
Hij heeft 10 jaar besteed aan deze DB en om nu een virtuele server te nemen is ook weer zoiets....

ik zie meteen een fout in de virtualisatie: ook dan moet je spullen over gaan zetten vrees ik.

Hoop dat er nog andere suggesties komen!

Het overzetten is geen punt, het vervelende is dat de DB niet compatible is met andere programma's omdat dit programma meer velden en opties heeft dan andere programma's.
Daardoor is er bij overzetten informatie overschot waar dat nieuwe programma niks mee kan. Ook relaties die gelegd worden gaan dan verloren of lopen mis.

Dezelfde applicatie gebruiken op een nieuwe pc kan dus wel...
Het is gewoon brak opgezet, de architectuur is niet herdacht toen ze zijn gaan groeien en zijn gewoon door gaan borduren.

Oorspronkelijk geplaatst door cyberbootje

Eigenlijk zou het mooiste zijn dat meerdere cores gebruikt kunnen worden en dat de app dit als 1 core ziet. (dus een 9Ghz cpu )
Dit is overigens op een standalone windows machine.

Had intel (i7) geen technologie om te 'stapelen'. Dus de cores op elkaar te stapelen?

Dacht dat ik dit in een presentatie van hun eens had gezien

Ik denk dat het uiteindelijk toch geen oplossing zal zijn. Daarbij weet je niet of de boel alsnog plat getrokken wordt aangezien de core nu op 100% loopt.

Misschien kun je de access db gewoon converteren naar mssql en eens kijken of een 'echt' dbms er sneller mee klaar is?

Oorspronkelijk geplaatst door Tim.Bracquez

Had intel (i7) geen technologie om te 'stapelen'. Dus de cores op elkaar te stapelen?

Dacht dat ik dit in een presentatie van hun eens had gezien

Is dat zo ja? Kan zo 123 even niet veel vinden dus als je een linkje hebt?

Oorspronkelijk geplaatst door systemdeveloper

Ik denk dat het uiteindelijk toch geen oplossing zal zijn. Daarbij weet je niet of de boel alsnog plat getrokken wordt aangezien de core nu op 100% loopt.

Misschien kun je de access db gewoon converteren naar mssql en eens kijken of een 'echt' dbms er sneller mee klaar is?

Nouja 100% load zal hem een worst wezen denk ik zo, hij heeft nu een aparte pc die 24 uur lang gaat blazen bij het samenvoegen van gegevens.

Al zou ik de access db kunnen omzetten, dan nog wil hij nog steeds die app gebruiken die de data moet bewerken en kloppend moet maken... of mis ik nu iets?

Daarnaast heb ik het idee dat er 0 formules in zitten. Hij doet, gok ik, brute force 1 op 1 velden vergelijken en dat 88.000 entries met elke entry 30 velden ofzo? en dan nog de relaties erbij...
Eigenlijk moet hij van dit programma af maargoed.... het is niet iets commercieels dus ik geloof niet dat hij dit wil laten herschrijven

Oorspronkelijk geplaatst door cyberbootje

Is dat zo ja? Kan zo 123 even niet veel vinden dus als je een linkje hebt?




Nouja 100% load zal hem een worst wezen denk ik zo, hij heeft nu een aparte pc die 24 uur lang gaat blazen bij het samenvoegen van gegevens.

Al zou ik de access db kunnen omzetten, dan nog wil hij nog steeds die app gebruiken die de data moet bewerken en kloppend moet maken... of mis ik nu iets?

Daarnaast heb ik het idee dat er 0 formules in zitten. Hij doet, gok ik, brute force 1 op 1 velden vergelijken en dat 88.000 entries met elke entry 30 velden ofzo? en dan nog de relaties erbij...
Eigenlijk moet hij van dit programma af maargoed.... het is niet iets commercieels dus ik geloof niet dat hij dit wil laten herschrijven

Mja, ik kan het me wel voorstellen: 10 jaar knutselen en vast geen regel documenteren, hehe
Het ligt er natuurlijk wel aan wat voor db acties het ding doet. Niet in alle gevallen ben je beter af met mssql tenslotte. Als het met name clientwerk is, dan heb je idd gewoon veel power nodig.
Maar als de maker zegt dat het 1M namen moet aan kunnen, waarom hem dan niet laten uitzoeken waarom het 8 uur staat te blazen op amper 88K namen? Misschien is er ergens gewoon iets rot gegaan (deel van db op bad sectors of zo iets stoms).

Nou het is gegaan in trant van: "1M moet ook lukken, er is geen limiet" dus ik heb het idee dat het vast kan, ook wel 2M of 5M maar hij zegt niks over de snelheid...

Maargoed het vervelende is dat ik niet ff de broncode kan bekijken, heb niet eens een idee waar het in gemaakt is zo uit het hoofd

Misschien is zo'n bakkie dat de GPU van grafische kaarten gebruikt een oplossing?

MS Access praat niet zomaar tegen de GPU, dan zal je de code moeten aanpassen en dan kan je met de upsizing wizard dat ding waarschijnlijk ook wel naar SQL server porten.
Of gewoon op elk veld een index zetten...

Is het niet mogelijk om meerdere instansies (workers) van die applicatie tegelijk te starten (poor mans multi threading)? Hierin moet je wel heel goed opletten of race conditions onmogelijk zijn!!!

Anders kan je kijken naar de I7 (of professioneler de xeon x56xx serie).
Deze hebben Intel® Turbo Boost Technology. Kortweg zorgt dit ervoor dat zodra maar 1 van de x cores heel zwaar belast worden en de overige cores bijna niet, dat hij cpu cycles gaat bijzetten op de actieve core ten nadelen van de rustige cores.