Új hozzászólás Aktív témák

• #62 moonman titán bambano #60

  Új Válasz 2009-11-15 19:23:22 #62

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  moonman

  titán

  válasz bambano #60 üzenetére

  96%-os piaci részesedésnél szerintem nincs azzal gond, ha valaki kicsit elnagyoltan alkalmazás=általános windows alkalmazás kifejezést használja. tudjuk, hogy a linuksz levegővel is üzemel és a rákot is gyógyíccsa, de most a Windows a téma.

• #61 dqdb nagyúr bambano #60

  Új Válasz 2009-11-15 19:20:06 #61

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dqdb

  nagyúr

  válasz bambano #60 üzenetére

  Az, hogy egy adott Windows változat maximum mennyi memóriát és hány processzort kezel, pusztán marketing (természetesen 32 bit esetén maximum 36 bitnyit tud megcímezni a PAE jóvoltából). Erre jó példa a 32 bites XP Pro maximum 4 GB-ja, a 32 bites Server 2003 Standard 4 GB-ja és a 32 bites Server 2003 Enterprise 32 GB-ja.

  Az, hogy egy 32 bites processz maximum 2 GB memóriát lát, már a kernel működéséből eredő technológia korlát. Ezt némileg fel lehet oldani (maximum 3 GB-ig növelhető a processz saját címtere), de nem teljesen büntetlenül.

  For applications that are memory-intensive, such as database management systems (DBMS), the use of a larger virtual address space can provide considerable performance and scalability benefits. However, the file cache, paged pool, and nonpaged pool are smaller, which can adversely affect applications with heavy networking or I/O. Therefore, you might want to test your application under load, and examine the performance counters to determine whether your application benefits from the larger address space.

Új hozzászólás Aktív témák